Method and system for remote television replay control

ABSTRACT

A method, system, computer medium, and other embodiments for integrating unrelated web hosted services with stand-alone media-based devices are provided. Users can access and control the media-based device conveniently with a web-browser through various portals on the Internet. In one embodiment, users access the media-based device through one or more unrelated web portals, so as to control and to program the media-based device in a single web session, and to see information both stored on the media-based device and originating from third-party online sources of information and services in a single integrated presentation.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority under 35 U.S.C. § 119(e) fromcopending and commonly assigned U.S. Provisional Application No.60/223,856, filed on Aug. 8, 2000 by Jeff Hastings, et al., entitled“Method and System for Remote Television Replay Control” the subjectmatter of which is herein incorporated by reference in its entirety.

[0002] This application claims priority under 35 U.S.C. § 119(e) fromcopending and commonly assigned U.S. Provisional Application No.60/248,313, filed on Nov. 14, 2000, by Jeff Hastings, et al., entitled“Method and System for Remote Television Replay Control” the subjectmatter of which is herein incorporated by reference in its entirety.

[0003] This application claims priority under 35 U.S. C. § 119(e) fromcopending and commonly assigned U.S. Provisional Application No.60/258,937, filed on Dec. 29, 2000, by Philippe Pignon, entitled “Methodand System for Remote Television Replay Control” the subject matter ofwhich is herein incorporated by reference in its entirety.

[0004] This application claims priority under 35 U.S.C. § 119(e) fromcopending and commonly assigned U.S. Provisional Application No.60/258,940, Docket No. JC804, filed on Dec. 29, 2000, by Millard E.Sweatt, III, entitled “Recording Television Programming via RemoteControl the subject matter of which is herein incorporated by referencein its entirety.

[0005] The subject matter of this application is related tocommonly-owned U.S. patent application Ser. No. XX/XXX,XXX, AttorneyDocket No. 5390, by Millard E. Sweatt, III, et al., entitled “Method andSystem for Remote Television Replay Control,” and which is being filedconcurrently with the present application on Aug. 8, 2001, the contentof which is hereby incorporated by reference in its entirety.

[0006] The subject matter of this application is related tocommonly-owned U.S. patent application Ser. No. XX/XXX,XXX, AttorneyDocket No. 5391, by Millard E. Sweatt, III, et al., entitled “Method andSystem for Remote Television Replay Control,” and which is being filedconcurrently with the present application on Aug. 8, 2001, the contentof which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

[0007] The present invention relates generally to enabling web userseasy access and control of media-based devices and appliances overcomputer networks, and more specifically, to a method, system andcomputer medium for remote control of a digital video recorder from aclient user interface both in communication with the Internet.

BACKGROUND OF THE INVENTION

[0008] Conventional techniques provide for control input of amedia-based device either directly or with a short-ranged remotecontroller. That is, typically the media-based device may be directlyprogrammed using the control panel disposed on the device itself or witha remote controller (i.e., typically handheld) in communication with themedia-based device. The hand-held remote controller provided controlinput from short-ranged distances about the device usually by directhardwired extension cable, or by some wireless medium, like for example,infrared and radio frequency. While these conventional techniques workwell for those situations where the user is physically located withinthe vicinity (e.g., typically in the same room as the media-based) ofthe device, they do not address the situation where the user is at adifferent physical location and is thereby unable to access the deviceat such short-ranges. Although there exists numerous reasons andsituations as to why the user would be physically away from the device,the details of such are less important as opposed to the overridingdrawback that the user is unable to control the media-based device froma location remote to the physical location of the media-based device. Itwill be apparent to those skilled in the art that the handheld remotecontroller may be designed to accommodate an increased range ofhardwired and/or wireless transmission; however, this alternative isstill unsatisfactory as it is cost prohibitive in proportion to anincrease in the transmission distance.

[0009] Consequently, what is needed is a solution to enable user controland programming of media-based devices and appliances from remotelocations. It would be desirable if the device could be accessed andcontrolled from anywhere in the world, like from a web browser in amanner that is convenient, familiar, and relatively simple to use.Furthermore, it would be advantageous if a web-based solution could beprovided in a manner that seamlessly integrates information frommultiple sources, like for example, from the media-based device andvarious media content providers as well as other online serviceproviders so that the combination of information is available to a userin a single web session. It would be beneficial if the devices andappliances could communicate with such providers of information andcontent, so as to automatically receive and send information therebetween. Finally, the method, system, and computer medium that isneeded, for enabling remote control of a media-based device and foraccessing related information, should also be available to various webservers including portals in a uniform manner such as through anapplication program interface.

SUMMARY OF DESCRIBED EMBODIMENTS

[0010] The described embodiments of the present invention utilize theworld wide web to overcome the limitations of the current state of theart concerning access and control of stand-alone media-based devices.Web users, content providers of the subject-matter being utilized withthe media-based device, and web-hosted service providers who typicallyprovide ancillary services, system administration and system maintenanceof the media-based devices may benefit from the described embodiments ofthe present invention, which enable the integration of stand-aloneapplications for media-based devices and appliances with web-hostedservices that by themselves do not necessarily work well with eachother. To this end, the described embodiments of the present inventionare beneficial in creating a web application, which may be offered as aweb-hosted service, for enabling existing stand-alone media-baseddevices to be more effective to a user.

[0011] The described embodiments of the present invention comprise amethod, system, computer medium, and other embodiments for integratingunrelated web-hosted services with stand-alone media-based devices andappliances, and for allowing users to access and control the media-baseddevice and/or appliance conveniently with a client user interface suchas a web-browser through various portals on the Internet. One technicalaspect of the present invention enables users to access the media-baseddevice and appliance through one or more unrelated web portals, so as tocontrol and to program the media-based device in a single web session.With this aspect of the present invention, users are provided with anintegrated presentation that includes information both stored on themedia-based device and appliance and that in one embodiment mayoriginate from third-party online sources of information and services.That is, rather than having to be in the same room as the media-baseddevice and appliance to provide control input thereto, the describedembodiments of the present invention overcome the limitations associatedwith conventional programming techniques and enables users to access themedia-based device from remote locations throughout the world via theInternet.

[0012] Another aspect of the present invention simulates an operationalstandalone media-based device and appliance over a network, whether thedevice or appliance is in periodic communication or continuouscontinuation with the network. According to one embodiment of thepresent invention, a virtual representation of the media-based deviceand appliance is created over the network and presented to the clientuser interface to simulate the operation of the media-based device. Inanother embodiment of the present invention, the media-based device andappliance communicates over the network in real-time and on-the-fly withthe client user interface.

[0013] According to yet another aspect of the present invention, whenthe information both stored on the media-based device and originatingfrom unrelated online sources are combined into an integratedpresentation and presented to a user through a single web session, userscan access and view the combined information through one webpresentation, and select and manipulate particular information ofinterest. These otherwise unrelated and disparately-located sources ofinformation include, but are not limited to, web-hosted and onlineservices concerning television, satellite-based, pay-per-view andcable-based television guide information, user preferences andauthentication information and other related and ancillary services.

[0014] The described embodiments are implemented with a client/serverarchitecture embodied in a computer-based communication system. Byenabling access and control of the media-based device and appliance overthe Internet using a “web paradigm,” the described embodiments of thepresent invention provide users with a convenient and efficient mannerfor programming the media-based device and appliance. In one embodiment,the media-based device and appliance comprises an interactive televisiondevice in the nature of a digital video recorder (DVR), also known as apersonal video recorder (PVR). By porting the local control interfacetypically utilized on the stand-alone DVR to enable control input from aclient user interface over a network, the described embodiment of thepresent invention provides a context for control input in which usersare increasing becoming familiar with due to the growing popularity ofthe Internet. The world-wide appeal of the Internet coupled with the webapplication to control the DVR allow a scalable solution without theintensive high-end costs for tooling and manufacturing.

[0015] One technical advantage of the present invention is that itincludes a computer-based communication system that is enabled to: (1)extract information from the stand-alone media-based device andappliance through a back end client-server subsystem; (2) extractinformation from online and unrelated web hosted services through yetanother server subsystem; (3) combine the extracted information from thevarious sources mentioned; (4) maintain a local representation of thecombined data on a database; (5) create an integrated presentation basedon combining the information extracted to simulate the operation of themedia-based device in either a virtual or real-time manner; (6) allowmultiple portals to make requests to a front end subsystem and toreceive the integrated presentation via an API (Application ProgramInterface); (7) transfer the integrated presentation to a client userinterface; (8) accept instructions from the client user interface inresponse to receiving the presentation in order to update the databaseand the media-based device and appliance; (9) combine the instructionsreceived with farther information obtained from the online andweb-hosted services; and (10) update the media-based device andappliance with the instructions and further information combined.

[0016] One aspect of the computer-based communication system of thepresent invention enables the communication between a network computingsystem, a network/media-based data integration system, and a media-basedcomputing system. In order for the network computing system tocommunicate with the media-based computing system through the dataintegration system, a set of processes embodied in an API is provided.In one embodiment, the network computing system includes web-hostedservices provided over the Internet, the web-hosted services beingexternal to the data integration system. In the same embodiment, thestandalone DVR is connected to a network in the media-based computingsystem. The API provided in the data integration system enables aflexible approach to allow various external web portals in the networkcomputing system to communicate with the DVRs in the media-basedcomputing system. Furthermore, the API enables clients on the networkcomputing system to request and to obtain the integrated presentation atthe client user interfaces in unique arrangements distinctive to thelocal environment of the web portal. Accordingly, the API exposes theintegrated presentation to be utilized by a wide range of websites formillions of users in a simple and easily accessible manner. The APIencapsulates a variety of functions that facilitate creating a useraccount, user login, user preferences, adding a request, obtainingprogramming guide information, finding television programs of interest,and others to be described more specifically herein.

[0017] In yet another technical aspect of the present invention, themedia-based computing system enables the communication of requests, dataand other control input information across various networks from a DVR.The DVR is also enabled to receive commands and to send out data andstatus information based on commands and data received across thevarious networks. In particular, the DVR is enabled to be programmedfrom an external source (e.g., preferably through a computer-basedcommunication system having multiple web servers) in a uniform manner.That is, instead of a conventional hand-held remote controller and thecontrol panel disposed on the DVR being the mechanisms used to programthe DVR, an external source may be used to facilitate the programming.

[0018] The features and advantages described in this summary and thefollowing detailed description are not all-inclusive, and particularly,many additional features and advantages will be apparent to one ofordinary skill in the art in view of the drawings, specification andclaims hereof. Moreover, it should be noted that the language used inthe specification has been principally selected for readability andinstructional purposes, and may not have been selected to delineate orcircumscribe the inventive subject matter, resort to the claims beingnecessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The teachings of the present invention can be readily understoodby considering the following detailed description in conjunction withthe accompanying drawings.

[0020]FIG. 1A is a high-level block diagram of a computer-basedcommunications system that enables the remote control of media-baseddevices and appliances over a communication network in accordance withthe present invention.

[0021]FIG. 1B is a high-level block diagram of an alternate embodimentof the computer-based communications system of FIG. 1A.

[0022]FIG. 2 is a block diagram showing a first embodiment of thecomputer-based communications system of FIG. 1A in accordance with thepresent invention.

[0023]FIG. 3 is block diagram of an embodiment of hardware for theclient-based computer, servers, and media-based devices in accordancewith the present invention.

[0024]FIG. 4A is a block diagram of the main memory unit of a clientcomputer.

[0025]FIG. 4B is a block diagram of the main memory unit of a server.

[0026]FIG. 4C is a block diagram of the main memory unit of the middletier server.

[0027]FIG. 4D is a block diagram of the main memory unit of amedia-based device and appliance.

[0028]FIG. 5 is an alternate embodiment of the computer-basedcommunication system of FIG. 1A.

[0029]FIG. 6 is a block diagram of the main memory unit of the batchrequest server.

[0030]FIG. 7 is an exemplary class diagram of related informationpertaining to a client user and a DVR.

[0031]FIG. 8 is a block diagram of the main memory unit of the RNSserver.

[0032]FIG. 9 is a block diagram of one embodiment of the back endenabling the RNS servers to receive EPG data from an online source inaccordance with the present invention.

[0033]FIG. 10 is a block diagram of an exemplary embodiment for aninteractive television sub-system having a digital video recorder inaccordance with the present invention.

[0034]FIG. 11 is an exemplary graphical representation of a userinterface for logging into and accessing the computer-basedcommunications system of the present invention.

[0035]FIG. 12A is an exemplary graphical representation of a userinterface for indicating the channel guide information.

[0036]FIG. 12B is an exemplary graphical representation of drop-downmenus for the user interface of FIG. 12A.

[0037]FIG. 13A is a block diagram showing the data flow throughout thecomputer-based communications system of FIG. 1A.

[0038]FIG. 13B is a sequence diagram of one implementation for login tothe front end and for “batched” communication at the back end of thecomputer-based communications systems of FIGS. 2 and 5.

[0039]FIG. 14 is a chart listing the functions implemented on oneembodiment of the API and the corresponding functions in accordance withthe present invention.

[0040]FIG. 15 is a chart listing the functions implemented on oneembodiment of the API and the corresponding input parameters and outputfiles.

[0041]FIG. 16A is a high level illustration of one embodiment of thefront end implementation in accordance with the present invention.

[0042]FIG. 16B is a data flow block diagram showing further details ofAPI in the front end of FIG. 16A.

[0043]FIG. 17 is a chart illustrating the multiple requests handled bythe AddRequest routine implemented as part of an embodiment of the API.

[0044]FIG. 18 is a flow chart illustrating one embodiment of a method ofimplementing the mechanism to respond to user requests based on the userinterface of FIG. 12A.

[0045]FIG. 19A is an exemplary graphical representation of a userinterface for indicating the Replay Guide information organized byReplay Channels.

[0046]FIG. 19B is an exemplary graphical representation of a userinterface for indicating the Replay Guide information organized byRecorded Shows.

[0047]FIG. 20 is a flow chart illustrating one method of implementingthe mechanism to respond to user requests based on the user interfaceillustrated in FIG. 19A.

[0048]FIG. 21 is a flow chart illustrating one method of implementingthe mechanism to respond to user requests based on the user interfaceillustrated in FIG. 19B.

[0049]FIG. 22 is an exemplary graphical representation of a userinterface for performing a search on the Find Shows page.

[0050]FIG. 23 is a flow chart illustrating one method for implementingthe mechanism to respond to user requests based on the user interfaceillustrated in FIG. 22.

[0051]FIG. 24A is an exemplary graphical representation of a userinterface for indicating a single recording on the manual record page.

[0052]FIG. 24B is an exemplary graphical representation of a userinterface for repeated manual recording.

[0053]FIG. 25 is a flow chart illustrating one method for implementingthe mechanism to respond to user requests based on the user interfaceillustrated in FIG. 24A.

[0054]FIG. 26 is a flow chart illustrating one method for implementingthe user login process.

[0055]FIG. 27 is a block diagram showing further details of anembodiment of the computer-based communications system of FIG. 1B inaccordance with the present invention.

[0056]FIG. 28 is a block diagram of an alternate embodiment of thecomputer-based communication system of FIG. 1B.

[0057]FIG. 29 is a block diagram of an alternate embodiment of thecomputer-based communications systems.

[0058]FIG. 30 is a detailed block diagram of the computer-basedcommunications system of FIG. 28.

[0059]FIG. 31 is high-level block diagram of a distributed architecturefor a load-balanced computer-based communications system.

[0060] The figures depict a preferred embodiment of the presentinvention for purposes of illustration only. One skilled in the art willreadily recognize from the following discussion that alternativeembodiments of the structures and methods illustrated herein may beemployed without departing from the principles of the inventiondescribed herein.

DETAILED DESCRIPTION OF EMBODIMENTS

[0061] Introduction

[0062] A system, method, computer medium and other embodiments foraccessing, reviewing and providing selective control input over acomputer-based communications system to media-based devices andappliances from client user interfaces are described. In the followingdescription, for purposes of explanation, numerous specific details areset forth in order to provide a thorough understanding of the invention.It will be apparent, however, to one skilled in the art that theinvention can be practiced without these specific details. In otherinstances, structures and devices are shown in block diagram form inorder to avoid obscuring the invention with unnecessary details.

[0063] Reference in the specification to “one embodiment” or to “anembodiment” means that a particular feature, structure, orcharacteristic described in connection with the embodiments is includedin at least one embodiment of the invention. The appearances of thephrase “in one embodiment” in various places in the specification arenot necessarily all referring to the same embodiment.

[0064] Some portions of the detailed description that follows arepresented in terms of algorithms and symbolic representations ofoperations on data bits within a computer memory. These algorithmicdescriptions and representations are the means used by those skilled inthe data processing arts to most effectively convey the substance oftheir work to others skilled in the art. An algorithm is here, andgenerally, conceived to be a self-consistent sequence of steps(instructions) leading to a desired result. The steps are thoserequiring physical manipulations of physical quantities. Usually, thoughnot necessarily, these quantities take the form of electrical, magneticor optical signals capable of being stored, transferred, combined,compared and otherwise manipulated. It has proven convenient at times,principally for reasons of common usage, to refer to these signals asbits, values, elements, symbols, characters, terms, numbers, or thelike. Furthermore, it has also proven convenient at times, to refer tocertain arrangements of steps requiring physical manipulations ofphysical quantities as (modules) code devices, without loss ofgenerality.

[0065] It should be borne in mind, however, that all of these andsimilar terms are to be associated with the appropriate physicalquantities and are merely convenient labels applied to these quantities.Unless specifically stated and otherwise as apparent from the followingdiscussion, it is appreciated that throughout the description,discussions utilizing terms such as “processing” or “computing” or“calculating” or determining” or “displaying” or the like, refer to theaction and processes of a computer system, or similar electroniccomputing device, that manipulates and transforms data represented asphysical (electronic) quantities within the computer system memories orregisters or other such information storage, transmission or displaydevices.

[0066] One aspect of the present invention includes an embodiment of theprocess steps and instructions described herein in the form of acomputer program. Alternatively, the process steps and instructions ofthe present invention could be embodied in firmware or hardware, andwhen embodied in software, could be downloaded to reside on and beoperated from different platforms used by real time network operatingsystems and applications.

[0067] The present invention also relates to an apparatus for performingthe operations herein. This apparatus may be specially constructed forthe required purposes, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but is not limited to, any type ofdisk including floppy disks, optical disks, CD-ROMs, magnetic-opticaldisks, read-only memories (ROMs), random access memories (RAMs), EPROMs,EEPROMs, magnetic or optical cards, application specific integratedcircuits (ASICs), or any type of media suitable for storing electronicinstructions, and each coupled to a computer system bus. Furthermore,the computers referred to in the specification may include a singleprocessor or may be architectures employing multiple processor designsfor increased computing capability.

[0068] The algorithms and displays presented herein are not inherentlyrelated to any particular computer or other apparatus. Variousgeneral-purpose systems may also be used with programs in accordancewith the teachings herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the present invention is not describedwith reference to any particular programming language. It will beappreciated that a variety of programming languages may be used toimplement the teachings of the present invention as described herein,and any references below to specific languages are provided fordisclosure of enablement and best mode of the present invention.

[0069] Moreover, the present invention is claimed below as operating onor working in conjunction with an information system. Such aninformation system as claimed may be the entire information system forproviding remote control of a digital video recorder and othermedia-based devices and/or appliances from browser and user interfaceapplications in communication with a network as detailed below in thedescribed embodiments or only portions of such a system. For example,the present invention can operate with an information system that needonly be a communications network in the simplest sense to facilitate thereview of program data and selections existing at the media-baseddevices and appliances. At the other extreme, the present invention canoperate with an information system that locates, extracts and storesdata from a variety of unrelated data sources and integrates such datawith user control input to program and update the media-based devicesand appliances as detailed below in the described embodiments or onlyportions of such a system. Thus, the present invention is capable ofoperating with any information system from those with minimalfunctionality, to those providing all of the functionality disclosedherein.

[0070] System Overview

[0071] Reference will now be made in detail to several embodiments ofthe present invention, examples of which are illustrated in theaccompanying drawings. Wherever practicable, the same reference numberswill be used throughout the drawings to refer to the same or like parts.

[0072] One aspect of the present invention addresses the situation wherethe media-based devices and appliances may not always be continuouslyconnected to a network. To address this situation, all of theinformation, that is necessary for the replication of what a user wouldexperience as if the media-based device acting as a stand-alone unit, isstored in a database. This information stored on the database, alongwith other sources of related information, allows the construction of anintegrated presentation to be sent to a client user interface, like abrowser, to simulate the operation of the media-based device functioningas if it were in a “live” (i.e., stand-alone) mode, that is, for viewingand control input. Accordingly, the present invention enables access toand control of the media-based device and/or appliance from a remotelocation and over a network whether or not the media-based device isparticipating in a communication session with a network in apeer-to-peer or periodic mode.

[0073] In one embodiment discussed below, when the media-based deviceand/or appliance periodically establishes a connection with a networkand database, information is pushed and pulled between the client,database and media-based device in a “batched” processing mode. In thisembodiment, the replication of data necessary to simulate using themedia-based device at a client can be analogized to virtualizing themedia-based device over a network.

[0074] With another embodiment discussed below, where the media baseddevice establishes a peer-to-peer communication session with the client,the control input and update of the media-based device and/or appliancefrom a client is executed “on-the-fly”, that is, in real time enablingnear instantaneous results.

[0075] 1. An Embodiment for Remote Control of Media-Based Devices andAppliances Through Batched Processing

[0076] Referring now to the block diagram of FIG. 1A, there is shown anexample of a computer-based communications system 10 that enables theremote control of media-based devices and appliances over acommunication network in accordance with the present invention. In theexample of FIG. 1A, communications system 10 includes a networkcomputing system 12 coupled to a network/media-based data integrationsystem 14 (henceforth “integration system 14”), which in turn, iscommunicatively coupled to a media-based computing system 16. Thenetwork computing system 12 enables multiple users to communicate over acommunications system 10 in order to access and control the media-baseddevices and appliances of media-based computing system 16 from a remotelocation. Media-based computing system 16 enables the media-baseddevices and appliances to be accessed through a network system, therebyfurther enhancing stand-alone capabilities of the devices andappliances. Integration system 14 provides the interface between thedifferent networks where users and media-based devices may be incommunication, and additionally provides a centralized repository forcapturing, combining and integrating data from multiple sources of dataand for providing the data captured to the client user interfaces andthe media-based devices.

[0077]FIG. 2 shows a block diagram of one embodiment of a communicationssystem 10A having further details of the communications system 10 ofFIG. 1A. In the embodiment shown in FIG. 2, communications system 10Aincludes a network computing system 12 a coupled to anetwork/media-based data integration system 14 a, which in turn iscommunicatively coupled to a media-based computing system 16 a. Inparticular, and by way of example, network computing system 12 a isbased on a client-server computer model which enables users to accesssupplying-computer devices from requesting-computer devices throughrequests made from a user interface provided at the requesting-computerdevices. As shown in FIG. 2, one embodiment of the client-servercomputer model that is well-suited for network computing system 12 acomprises one or more client computers 18 (used interchangeably with“client applications 18” and “clients 18”) each having a user interface,e.g., like a browser 20, to communicate 22 with network 24. Network 24is, in turn, communicatively coupled 26 to one or more server computers28-1 to 28-n (referred to interchangeably as servers 28-1, 28-2, . . . ,28-n). For convenience in describing the present invention, reference to“server computers” will be used interchangeably with “servers.” In turn,servers 28-1, 28-2, . . . , 28-n are communicatively coupled tointegration system 14 a, as indicated by data lines 30.

[0078] Also shown in the embodiment of FIG. 2, media-based computingsystem 16 a is similarly based upon a client-server computer model. Forconvenience and ease of understanding the present invention, themedia-based computing system 16 a will be referenced interchangeablyherein as the “back end sub-system 16 a,” and “back end 16 a.” As seenin the embodiment of FIG. 2, the back end sub-system 16 a includes aplurality of RNS servers 32 coupled 34 to a plurality of media-baseddevices and appliances 36. For ease of understanding the invention andconvenience, reference to “media-based devices and appliances 36” willinterchangeably be made to “media-based devices 36.” As will bedescribed more specifically later, media-based devices 36 additionallyinclude functionality to perform communication tasks similar to clientcomputers, and RNS servers 32 are additionally designed to operatesimilarly to the server computers in the client-server computer model.As will be described subsequently in further detail, the RNS servers 32may communicate with the media-based devices 36 over network 38.

[0079] In between the network computing system 12 a and the back endsub-system 16 a, the network/media-based data integration system 14 aprovides a centralized interface there-between. For convenience and easeof understanding the present invention, system 14 a will be referencedinterchangeably as the “front end sub-system 14 a,” and “front end 14a,” relative to the back end sub-system 16 a. Collectively, the frontend 14 a and the back end 16 a comprise the “My Replay TV” (MRTV) systemin accordance with the present invention. In general, front end 14 aextracts, captures, stores, and integrates information from a variety ofdisparate data sources and transmits the information assembled to theclient user interfaces, like at browser 20, and to the media-baseddevices 36. Additionally, front end 14 a enables data from a variety ofsources to be shared across systems 12 a and 16 a, and in doing so,facilitates user control input for media-based devices 68 overcommunications system 10A. In the embodiment of FIG. 2, the front end 14a includes a middle tier server 40 coupled 42 to a database 44 and toservers 28-1, . . . , 28-n, over data lines 30. The database 44 iscommunicatively coupled 46 to a batch request server 48, and otheronline sources of data, such as database 50 over data line 52 and anonline service 54 over data line 56, by way of example. Batch requestserver 48 is capable of communication with RNS server 32 over data line58, and directly over line 60 with media-based devices 36.

[0080] One embodiment of network 24 in accordance with the presentinvention includes the Internet. However, it will be appreciated bythose skilled in the art that the present invention works suitably-wellwith a wide variety of computer networks over numerous topologies, solong as network 24 connects the distributed clients 18 to servers 28-1to 28-n. For convenience and ease of understanding the presentinvention, at times, reference will be made to network 24 as theInternet 24. However, it is noted that the present invention is notlimited by the type of network described. Thus, to the extent thediscussion herein identifies a particular type of network, suchdescription is purely illustrative and is not intended to limit theapplicability of the present invention to a specific type of network.For example, other public or private communication networks that can beused for network 24 include Local Area Networks (LANs), Wide AreaNetworks (WANs), intranets, extranets, Virtual Private Networks (VPNs),and wireless networks (i.e., with the appropriate wireless interfaces asknown in the industry substituted for the hard-wired communicationlinks). Generally, these types of communication networks can in turn becommunicatively coupled to other networks comprising storage devices,server computers, databases, and client computers that arecommunicatively coupled to other computers and storage devices.

[0081] Clients 18, servers 28-1 to 28-n, servers 32, 40 and 48 andmedia-based devices 36 may beneficially utilize the present invention,and may contain an embodiment of the process steps and modules of thepresent invention in the form of a computer program. Alternatively, theprocess steps and modules of the present invention could be embodied infirmware, or hardware, and when embodied in software, could bedownloaded to reside on and be operated from different platforms used byreal time network operating systems and applications.

[0082] A. Exemplary Embodiment for Clients

[0083] Each user at client 18 works with communications system 10A toseamlessly access one or more of servers 28-1 through 28-n throughnetwork 24. Referring now to the block diagram of FIG. 3, one embodimentfor the client computer 18 is shown. The client computer 18 comprises acontrol unit 62 coupled to a display device 64, a keyboard 66, a controlinput device 68, a network controller 70, and an Input/Output (I/O)device 72 by a bus 74.

[0084] Control unit 62 may comprise an arithmetic logic unit, amicroprocessor, a general purpose computer, a personal digital assistantor some other information appliance equipped to provide electronicdisplay signals to display device 64. In one embodiment, control unit 62comprises a general purpose computer having a graphical user interface,which may be generated, for example, by a program written in the Javalanguage running on top of an operating system like the WINDOWS® orUNIX® based operating systems. In the embodiment of FIG. 3, one or moreapplications, electronic mail applications, spreadsheet applications,database applications, and web browser applications, generate thedisplays, store information, and retrieve information as part ofcommunications system 10A (and 10B as will be described in detailsubsequently). The control unit 62 also has other conventionalconnections to other systems such as a network for the distribution offiles (e.g., media objects) using standard network protocols such asTCP/IP, HTTP, LDAP and SMTP as will be understood by those skilled inart.

[0085] It should be apparent to those skilled in the art that controlunit 62 may include more or less components than those shown in FIG. 3,without departing from the spirit and scope of the present invention.For example, control unit 62 may include additional memory, such as, forexample, a first or second level cache, or one or more applicationspecific integrated circuits (ASICs). Similarly, additional componentsmay be coupled to control unit 62 including, for example, image scanningdevices, digital still or video cameras, or other devices that may ormay not be equipped to capture and/or download electronic data tocontrol unit 62.

[0086] Also shown in the embodiment of FIG. 3, the control unit 62includes a central processing unit (CPU) 76 (otherwise referred tointerchangeably as a processor 76), a main memory unit 78, and a datastorage device 80, all of which are communicatively coupled to a systembus 74.

[0087] CPU 76 processes data signals and may comprise various computingarchitectures including a, complex instruction set computer (CISC)architecture, a reduced instruction set computer (RISC) architecture, oran architecture implementing a combination of instruction sets. Althoughonly a single CPU is shown in FIG. 3, multiple CPUs may be included.

[0088] Main memory unit 78 can generally store instructions and datathat may be executed by CPU 76. Generally, main memory unit 78 may be adynamic random access memory (DRAM) device, a static random accessmemory (SRAM) device, or some other memory device known in the art, byway of example. FIG. 4A shows further details of a particular embodimentof a main memory unit 78A for a client computer 18, by way of example.In the embodiment of FIG. 4A, the memory unit 78A preferably includes anInternet (web) browser application 82 (20) being of conventional typethat provides access to the Internet and processes HTML, DHTML, XML,XSL, or other mark-up language to generate images on the display device64. As is known in the art, a web browser facilitates the viewing of aweb page on the Internet, wherein a user enters a Uniform ResourceLocator (URL) of the web page or clicks on a hyperlink to the web page.By doing so, the web page itself is fetched from the appropriate webserver. Several examples of web browser applications 82 include theNetscape Navigator or Microsoft Internet Explorer browser. The mainmemory unit 78A also includes a network application program 85 andoptionally a client program 86 to enable communication between theclient computer 18 and the servers 28-1 to 28-n. Network application 85functions with network controller 70 to establish communication betweenclient 18 and network 24. Client program 86 may function with browser 82for creating, editing, moving, adding, searching, removing and/orviewing information related to the media-based devices 36 (unlessbrowser 82 includes such functionality) described in accordance with thepresent invention. The memory unit 78A may also include one or moreapplication programs 87, including without limitation, word processingapplications, electronic mail applications, and spreadsheetapplications. Also, main memory unit 78A includes an Operating System(OS) 84. For example, OS 84 may be of conventional type such as WINDOWS®98/2000 based operating systems. In other embodiments, the presentinvention may additionally be used in conjunction with any computernetwork operating system (NOS), which is an operating system used tomanage network resources. A NOS may manage multiple inputs or requestsconcurrently and may provide the security necessary in a multi-userenvironment. An example of an NOS that is completely self-containedincludes WINDOWS® NT manufactured by the Microsoft Corporation ofRedmond, Wash. Those skilled in the art will recognize that, in general,main memory unit 78A may include other features than those illustrated.The instructions and data may comprise code devices for performing anyand all of the techniques described herein.

[0089] Referring back to FIG. 3, data storage device 80 stores data andinstructions for CPU 76 and may comprise one or more devices including ahard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device,a DVD-RAM device, a DVD-RW device, a flash memory device, or some othermass storage device known in the art.

[0090] System bus 74 represents a shared bus for communicatinginformation and data through control unit 62. System bus 74 mayrepresent one or more buses including an industry standard architecture(ISA) bus, a peripheral component interconnect (PCI) bus, a universalserial bus (USB), or some other bus known in the art to provide similarfunctionality.

[0091] Additional components coupled to control unit 62 through systembus 74 will now be described, and which include display device 64, akeyboard 66, a control input device 68, a network controller 70, and anI/O device 72. Display device 64 represents any device equipped todisplay electronic images and data as described herein. Display device64 may be a cathode ray tube (CRT), a liquid crystal display (LCD), orany other similarly equipped display device, screen or monitor.Alternatively, other embodiments of display device 64 corresponding tothe alternative embodiments of client 18, can include by way of example,the touch panel Liquid Crystal Display (LCD) of a Personal DigitalAssistant (PDA), and the display screen of a cellular phone.

[0092] Keyboard 66 represents an alpha-numeric input device coupled tocontrol unit 62 to communicate information and command selections to CPU76. Control input device 68 represents a user input device equipped tocommunicate positional data as well as command selections to CPU 76.Control input device 68 may include a mouse, a trackball, a stylus, apen, a touch screen, cursor direction keys, joystick, touchpad, or othermechanisms to cause movement of a cursor. Network controller 70 linkscontrol unit 62 to network 24 and may include network I/O adapters forenabling connection to multiple processing systems. The network ofprocessing systems may comprise a LAN, WAN, and any other interconnecteddata path across which multiple devices may communicate.

[0093] One or more input/output devices 72 are coupled to system bus 74.For example, I/O device 72 could be an audio device equipped to receiveaudio input and transmit audio output. Audio input may be receivedthrough various devices including a microphone within I/O device 72 andnetwork controller 70. Similarly, audio output may originate fromvarious devices including CPU 76 and network controller 70. In oneembodiment, I/O device 72 is a general purpose audio add-in expansioncard designed for use within a general purpose computer. Optionally, I/Odevice 72 may contain one or more analog-to-digital or digital-to-analogconverters, and/or one or more digital signal processors to facilitateaudio processing.

[0094] Having described one embodiment for the hardware of clientcomputer 18, it will be appreciated by those skilled in the art thatalternative embodiments exist for client 18, besides the computerhardware shown in FIG. 3. Such alternative embodiments that may besubstituted for client 18 can include portable hand held devices thatare processor-based, as will be recognized by those skilled in the art.By way of example, several portable hand held devices that may besubstituted for client 18 include PDAs, two-way pagers, email terminals,Global Positioning Systems (GPS), and mobile/cellular phones. When suchalternative embodiments are utilized with the present invention, it willbe recognized by those skilled in the art that the user interface,communication medium and protocol adapters described for the embodimentof FIG. 3 should be modified to comply with the correspondingmedia-enabled portable wireless devices. For example, the presentinvention also has described embodiments for a set of protocol adaptersthat interface to a variety of Internet protocols, including but notlimited to, HTML, DHTML, POP3, SMTP, SNMP, FTP, NFS, IMAP, NNTP, andWAP. It will be recognized by those skilled in the art that web browsers20, 82 may be modified to be used on media-enabled portable wirelessdevices in connection with the corresponding communication protocol.Further, it will be apparent that data flow lines 22 wouldcorrespondingly represent a wireless communication medium (e.g., radiofrequency signals, infrared signals) as appropriate for wirelesstransmission of signals.

[0095] B. Exemplary Embodiment for Server Computers

[0096] Referring now to the block diagrams of FIGS. 3 and 4B, theservers 28-1 through 28-n included in the embodiment of networkcomputing system 12 a will be described in more detail. For convenienceand ease of understanding the invention, reference will interchangeablybe made to “servers 28” to generically describe features of servers 28-1through 28-n. Also for convenience, like reference numerals have beenused for similar components used in both the client computer 18, and theservers 28. Servers 28 are generally responsible for presenting thefront end 14 a of computer system 10A to a user at the client 18. In oneembodiment, servers 28 may be web portals, which is defined to mean aweb “supersite” that provides a variety of online services.Alternatively, servers 28 may be web-sites provided by and/or web-hostedby unrelated entities and system administrators. These particularembodiments are well-suited for the situation when network 24 is theInternet.

[0097] In the embodiment of FIG. 3, server 28 preferably includes adisplay 64, a keyboard 66, a control input device 68, a first networkcontroller and interface (I/F) 70, an I/O device 72, and a secondnetwork controller and interface (I/F) 73, coupled together via bus 74.Server 28 further includes a control unit 62 having a processor 76,memory unit 78, and a data storage device 80 also coupled to bus 74. Asshown in FIG. 3, the first network controller and I/F 70 iscommunicatively coupled via 26 to the network 24, and ultimately toclient 18. The second network controller and I/F 73 is communicativelycoupled to the front end 14 a, and as shown in FIG. 2, by data line 30.The processing unit 76 processes data signals and may comprise variouscomputing architectures including CISC or RISC architecture, or anarchitecture implementing a combination of instruction sets. In oneembodiment, server 28 includes a multiple processor system having a mainmemory unit 78B, as will be described in FIG. 4B. As an example, aWINDOWS® NT/2000 server can be used for server 28, while other multipleprocessor systems may work suitably well with the present invention,including the Dell 1800 made and sold by Dell Computer Corporation.

[0098] Referring now to FIG. 4B, further details of a particularembodiment of a main memory unit 78B for a server 28 are shown, by wayof example. In the embodiment of FIG. 4B, the memory unit 78B preferablycomprises an operating system 88, other applications 90, serverapplication programs 92 (“servers 92”), and a “front end” serverapplication 94, all communicatively coupled together via system bus 74.Server 92 may be any conventionally known server application, like forexample, an Apache HTTP server. Front end server application 94 is aninterface for establishing communication with the middle tier server 40by sending and receiving requests and data to the API, which will bedescribed subsequently. In general, servers 28 may host front end 14 aand are typically external websites relative to systems 14 a and 16 a.Because servers 28 can represent a variety of general purpose websites,some functioning as a “supersite” that provide various online services,while others being for more limited purposes, for convenience and toavoid obscuring the invention with unnecessary details, reference toservers 28 will interchangeably be made herein to “web portals 280.” Thememory unit 78B may also include one or more other application programs90 including, without limitation, word processing applications,electronic mail applications, and spreadsheet applications. A networkapplication module 98 is part of network controller 70 which enablesserver 28 to communicate with network 24 over lines 26. Optionally, abrowser 96 may be included. As noted above, the memory unit 78B storesinstructions and/or data that may be executed by processing unit 76. Theinstructions and/or data may comprise code for performing any and/or allof the techniques described herein. These modules 88, 90, 92, 94, and 96in addition to others not specifically shown, are coupled by system bus74 to the processing unit 76 for communication and cooperation toprovide the functionality of the server 28. Those skilled in the artwill recognize that while the present invention will now be described asmodules or portions of the memory unit 78B of a computer system, themodule or portions may also be stored in other media such as permanentdata storage and may be distributed across a network having a pluralityof different computers such as in a client/server environment.

[0099] Referring back to FIG. 2, in accordance with the presentinvention, network 24 enables the communication between multiplecomponents of servers 28 and clients 18, as well as other devices, whichmay or may not be co-located, but may be distributed for convenience,security or other reasons. To facilitate the communication betweenclient 18 and server 28, a client-server computer network operatingsystem (NOS) may be used for operating system 88 in memory unit 78B ofFIG. 4B to manage network resources. An NOS can manage multiple inputsor requests concurrently and may provide the security necessary in amulti-user environment. Operating system 88 can include, for example, aNOS of conventional type such as a WINDOWS® NT/2000, and UNIX® used withthe Microsystem SOLARIS® computing environment. Another conventionaltype of operating system that may be used with the present inventionincludes LINUX® based operating systems.

[0100] C. Exemplary Embodiment for the Front End

[0101] Still referring to the block diagram of FIG. 2, more detailsabout an embodiment of the front end 14 a will now be discussed. Frontend 14 a includes a middle tier server 40, to which servers 28communicate with. Front end 14 a further includes a database 44 coupled42 to the middle tier server 40, which in turn, is coupled 46 to aserver 48 for providing information from the front end 14 a to the backend 16 a in “batches,” (i.e., periodically). Various other databases 50and online data sources 54 are in communication (52 and 56,respectively) with database 44.

[0102] Prior to describing other aspects of the present invention indetail, several definitions will now be introduced in the context of aparticular embodiment of the present invention, where the media-baseddevices 36 are DVRs 37. By way of example, in a particularimplementation where media-based devices 36 are DVRs 37, database 44stores at least: 1) for every DVR 37, a list of configured channels; and2) Electronic Program Guide (EPG) data for all channels by nationalbroadcasters. Although the particular embodiment of DVR 37 will bediscussed in more detail subsequently with reference to FIG. 10, thefollowing definitions are now provided by way of illustration and forease of understanding the invention.

[0103] The Electronic Program Guide (EPG) is defined to mean television(TV) guide data represented in electronic form, and provided from anonline data source, like for example, Tribune Media Services (TMS), aswill be discussed subsequently with respect to the TMS FTP server 112 ofFIG. 5. As conventionally known, FTP is defined to mean File TransferProtocol. In general, the EPG includes a broadcast schedule oftelevision, cable, and pay-per-view shows offered by nationalbroadcasters. An exemplary representation of the EPG data is the ReplayGuide that is shown in FIGS. 19A-B.

[0104] The Channel Guide is defined to mean a listing of all showsassembled from the EPG that will be broadcast, as will be discussed infurther detail subsequently with reference to FIG. 12A, showing oneexemplary list of configured channels includes the Channel Guide 190.The Channel Guide contains a list of channel lineup indicating theactual channels to be selected by the user to appear in the ReplayGuide. In general, the Channel Guide is an interactive on-screen programguide that lists upcoming and past programs broadcast.

[0105] The Replay Guide is defined to mean those shows that have beenselected by the user to be recorded as they are broadcast, and that areeither stored or to be stored in memory, as will be further describedwith reference to FIGS. 19B. In general, the Replay Guide includesuser-created record channels and current recorded shows. Replay Show isdefined to mean a particular view of the Replay Guide, wherein for eachprogram to be recorded, a distinct Replay Channel is assigned, as willbe further described with reference to FIG. 19A.

[0106] Replay Channel is defined to mean a particular view of the ReplayGuide, indicating descriptions associated with pending and completedprogram recording requests invoked according to either a search-basedcriteria or the Channel Guide criteria, as will be further describedwith reference to FIG. 12A. A Replay Channel may include a collection ofReplay Shows.

[0107] The Replay Zone is defined to mean television and videoprogramming organized by categories selected by the user.

[0108] i. Middle Tier Server

[0109] Referring back to FIG. 2, the middle tier server 40 iscommunicatively coupled to least one database 44, as indicated by dataline 42. Furthermore, middle tier server 40 is communicatively coupledto servers 28 as indicated by data lines 30. User requests originated byclients 18 and communicated through servers 28 are received at themiddle tier server 40. The requests are processed by server 40 accordingto a set of functions preferably embodied in an API 264, as will bediscussed with respect to FIG. 16B. For convenience and to providefurther clarification in distinguishing between multiple sets of APIsused throughout system 10A, reference to the API residing on the middletier server 40 will interchangeably be made to the MyReplayTV (MRTV) API264. In general, the API 264 can be accessed by servers 28 through HTTPcalls that are received by the middle tier server 40. As will bedescribed in more detail subsequently, the API 264 includes the: (1)procedural and functional calls, parameters, and formattingspecifications to enable data transfers amongst the interactivemedia-based devices 36 and 37 and the web portals 28 through the frontend subsystem 14 a; and (2) the software used on the middle tier server40 to create a virtual representation of an operational DVR 68B in anintegrated presentation to be presented to a client 18. The API 264 alsoenables the external devices in the network computing system 12 a toaccess information throughout the front end 14 a and to communicate withthe back end 16 a.

[0110] More details of the particular implementation of the middle tierserver 40 shown in FIG. 2 are illustrated in FIG. 3. The middle tierserver 40 may have the general hardware structure described with respectto client 18 and server 28 as seen in FIG. 3. It will become apparent tothose skilled in the art that like reference numerals are used in FIG. 3for describing the general hardware of the middle tier server 40primarily for convenience and so as not to obscure the invention withunnecessary details. To this end, server 40 includes a control unit 62having a processor 76, main memory 78, and data storage device 80.Control unit 62 is coupled via bus 74 to a display device 64, keyboard66, control input device 68, one or more network controllers 70 and 73,and I/O device 72.

[0111] A particular embodiment of main memory unit 78C is shown in FIG.4C for the middle tier server 40. Main memory 78C includes an operatingsystem 88 as already described, and includes server tools, such as, Javaservlets 100 running on an Apache web server 102 with a Tomcat (servlet)server. Tomcat, is a reference implementation combining the Java servlet100 and JavaServer PagesTM (JSP) 104 specifications which can run instandalone mode or be integrated into the Apache web server 102. Byusing Tomcat, an operational definition for the Enterprise JavaTM JSP104 and servlet 100 drives the Application Programming Interface (API)264 provided in accordance with the present invention. Java servlets 100can be written to run on middle tier server 40 that accept requests viaHTTP format and to transmit data in XML format to and from database 44.These Java servlets 100 provide functionality for converting the XMLfiles into data that can be stored in database 44, and for extractingdata from database 44, converting the extracted data into XML beforesending the converted data to an external client 18 via web servers 28.It is preferable that the Java servlets 100, incorporating the functionsof database interactions and the conversion of data format to XML, beshared between the Java applications that run on the RNS servers 32 andthe Java servlets 100 that run on the middle tier server 40. The memoryunit 78C for the middle tier server 40 can further include applicationsin the nature of Java applets 106, CGI scripts 108, database interfaceapplications 110 and other applications 90 (as previously described).Generally, the API 264 executes under the control of the Java servlets100. The Apache web server 102 is capable of generating an HTTP pagehaving a virtual representation of the control-input interface of DVR 37and for display on browser 20 and 82.

[0112] The database interface applications 110 are one or more programsthat include functionality for accessing, storing, and extracting datafrom a wide variety of relational computing systems such as databases,and which may be implemented by conventionally known techniques. Forexample, the database interface applications module 110 can be embodiedas a program for extracting and defining schema from any relational datasources that can be reached using Object Linking and Embedding DataBase(OLE DB), Open DataBase Connectivity (ODBC), and/or Java DataBaseConnectivity (JDBC) software drivers.

[0113] It should be apparent to one skilled in the art that memory unit78C may include more or less components than those shown in FIG. 4Cwithout departing from the spirit and scope of the present invention.

[0114] ii. Online Services and Databases

[0115] The database 44 in FIG. 2 will now be described morespecifically. Database 44 represents any relational database system,table or view. Preferably, any OLE DB, ODBC, or JDBC compliant databaseis well-suited to work with the present invention. Although a singledatabase 44 is shown in FIG. 2, multiple heterogeneous databases may beincluded. Examples of such databases include: Microsoft SQL server,Oracle, Informix, DB2, Sybase and Microsoft Access. Both the middle tierserver 40 and the batch request server 48 may store and extract datafrom database 44. For example, one manner of extracting information asindicated by data flow line 42 is using JDBC to access user profileinformation from the database 44.

[0116] Database 44 stores information received from various sources,like for example, an online service 54 coupled thereto by line 56. Oneparticular online service is provided by Tribune Media Services (TMS),and is shown in the embodiment of FIG. 5, where a TMS FTP server 112provides a feed to the MPREG module 114 of electronic programming guide(EPG) data into database 44, as will be described in more detailsubsequently. A Cruncher module 116 may be provided to load selected EPGdata into the DVR 37 via RNS server 32. Optionally, other databases maybe coupled to database 44 to provide specific types of information todatabase 44, as indicated by data line 52. For example, a userauthentication database 50 may be included in front end 14 a toauthenticate users against a collection of personal profile information.One particular proprietary user authentication database 50 that may worksuitably well with the present invention is a Silknet™ database. It willbecome apparent to those skilled in the art that additional onlinesources of data, including third-party search engines and other onlinecontent-providers, may provide additional information (e.g., content,broadcast, show and movie clips, chat rooms, etc . . . ) to database 44for integration with existing information, functions, features andservices. As shown in FIGS. 2 and 5, database 44 is coupled to a batchrequest server 48 as shown by line 46. It will be appreciated thatnumerous configurations of databases may work suitably well with thepresent invention, in addition to the particular implementation shown inFIGS. 2 and 5, where database 44 is configured as a hub that iscommunicatively coupled to other sources of information for receivinginformation to be combined with other data stored therein.

[0117] iii. Batch Request Server

[0118] Referring to FIGS. 2 and 5, server 48 will now be discussed indetail, with occasional reference made to FIGS. 13A-B. For convenienceand ease of understanding the invention, server 48 will be referencedinterchangeably with the “batch request server 48.” Server 48 isprovided for “batching” requests, meaning that periodically acommunication session is established between database 44 and server 48to pull data from the database 44 to the server 48 and/or to push datafrom server 48 to database 44. Additionally, periodic sessions areestablished between batch request server 48 and the RNS servers 32 toexchange data there between. As will be recognized by those skilled inthe art, the particular embodiment of server 48 in FIGS. 2 and 5provides “batched” communications between the front end 14 a and theback end 16 a, rather than a continuous real-time communication sessiondirectly between media-based devices 36 and the database 44 in aload-balanced distributed communication system as will be described inanother embodiment subsequently.

[0119] One aspect of providing “batch” communications with server 48 isto minimize the possibility of impacting the reliability of the RNSservers 32 as the number of media-based devices 36 scales upward. It isnoted that there are a variety of ways to preserve the reliability ofthe RNS servers 32. As will become apparent to those skilled in the art,batch request server 48 can include similar components in FIG. 3, adescription of which has already been described.

[0120] One particular implementation of batch request server 48 will nowbe discussed, by way of example, with reference to FIG. 6. In FIG. 6, ablock diagram of a main memory unit 120 is shown of a batch requestserver 48 having software modules therein that facilitate the “batch”processing functions described herein. As seen in FIG. 6, main memoryunit 120 includes a first module 122 for “pushing” data to themedia-based devices 36 through the RNS servers 32. In order toaccomplish this function, module 122 can be designed to query 243 thedatabase 44 in order to extract 245 data in the nature of all of themedia-based devices 36 that have been registered to use systems 10A and10B. A convenient parameter for discerning the registration dataextracted is by way of tracking serial numbers associated with eachdevice 36. Other parameters that may be useful for querying the database44 include those shown in the class diagram of FIG. 7, by way ofexample.

[0121] To provide further illustration, an implementation of module 122will now be discussed. Module 122 may be embodied as a script andinvoked as a CRON job, resulting with the extracted data placed into aBereklyDB file. More specifically, with this particular example, theCRON job can run a Java program: that periodically queries database 44for transaction information concerning the devices 36 that converts eachtransaction into an XML snippet; and that constructs a single-indexedBerkelyDB file containing all transactions since the last query arrangedby serial number of the media-based devices 36. The BerkelyDB filepreferably includes the transactions for all devices 36 formatted inXML. Once the data has been extracted, module 122 pushes 247 theBereklyDB file to all RNS servers 32 using the RSYNC command and asdescribed further during a discussion regarding Load Sharing Servers.

[0122] Referring back to FIG. 6, batch request server 46 may furtherinclude a second module 124 for pushing transactions to the RNS servers32. Second module 124 can be designed to query database 44 for a list ofpending transactions for all of the media-based devices 36. Similar tomodule 122, module 124 can be embodied as a script and invoked as a CRONjob, having the extracted data being placed in a BerkelyDB file. Thefile can then be pushed to all of the RNS servers 32.

[0123] Main memory unit 120 can include a third module 126 thatfunctions to monitor a particular folder for a file that the batchrequest server 48 pulls from the RNS servers 32. The particular folderpreferably includes all of the transaction result files assembled fromall of the RNS servers 32. Third module 126 preferably includes a Javaprogram to convert the format of the result files into XML formatteddata, which may be stored in database 44. Similar to modules 122 and124, third module 126 can be embodied as a script and invoked as a CRONjob that periodically collects the transaction result files using theRSYNC command.

[0124] D. Exemplary Embodiment for the Back End

[0125] Referring to FIG. 2, communicatively coupled to the front end 14a is a backend sub-system 16 a which in one embodiment comprises one ormore media-based devices 36 coupled to the front end 14 a. In anotherembodiment, a plurality of media-based devices 36 are coupled to atleast one of a plurality of load sharing servers 32, which in turn,communicate with the front end 14 a. More details of these embodimentsare discussed below.

[0126] j. Load Sharing Servers

[0127] Referring to FIG. 2, one embodiment is shown of a back end 16 ahaving a plurality of media-based devices 36 each being communicativelycoupled to the front end 14 a as indicated by control data line 60. Thisembodiment works suitably well for a limited number of media-baseddevices. As larger volumes of media-based devices 36 are provided, backend 16 a must be modified to accommodate the increased communicationtraffic and loads.

[0128] With another embodiment of back end 16 a, a mechanism forundertaking load-balancing of the communication between front end 14 aand a plurality of media-based devices 68 will now be discussed indetail still referring to FIG. 2. As shown in FIG. 2, the back endsub-system 16 a includes a plurality of media-based devices 36 that arein communication with at least one of a plurality of load sharingservers 32. For convenience and by way of example, reference will bemade interchangeably to the load sharing servers 32 as Replay NetworkService (RNS) servers 32. As will become evident from the discussionbelow, one technical benefit of RNS servers 32 is that they enable thesystem 10A to scale to large volumes of media-based devices 36 whileproviding flexibility and the expandability required for deploying adiverse set of applications.

[0129] With regard to control/data line 34, although each media-baseddevice 36 can be directly coupled to an RNS server 32, a preferredmanner is to communicatively couple media-based devices 36 over anetwork 38 (shown in broken line) to the RNS servers 32. By doing so,back end 16 a functions as a distributed sub-system of media-baseddevices 36. Data communication line 58 indicates that the RNS servers 32are coupled to the front end 14 a through the batch request server 48.It is noted that the present invention works suitably well withoutservers 32, but as the number of media-based devices 36 increases,servers 32 become beneficial for providing load balancing. That is, asthe number of media-based device 36 and DVRs 37 increase, a single RNSserver 32 can easily become overloaded, and thereby result in a failureof network communications.

[0130] In the same embodiment, back end sub-system 16 a can beanalogized to a client-server computer model which enables themedia-based devices 36 to access the RNS servers 32 over a network 38,which in one implementation may be the Internet. Back end sub-system 16a comprises a distributed set of RNS servers 32, which areload-balanced, for example, by using a load balancing Domain NamingService (DNS) server. A DNS server is a directory service whose generalfunction is to facilitate a mapping of Internet host names to InternetProtocol (IP) addresses with a complete fault tolerance system, as isknown in the art. Furthermore, a plurality of load-balanced DNS serverscan be web-hosted at different server farms on the Internet; and DVRs 37can be directed to the appropriate server farm on the Internet based ona random algorithm which is intended to be replaced with one that isgeographically optimized.

[0131] As described herein, there are several ways the communicationbetween the RNS servers 32 and the DVRs 37 may be established. The flowof data there between may be categorized based on the pull, push orbroadcast models. The pull model is defined to mean that each DVR 37connects (e.g., dials into) periodically to a RNS server 32 looking toupload requests being transmitted from the front end 14 a. The requestsreceived by the DVR 37 may be placed in a “to do” list. Although anexemplary particular implementation of the pull model will be discussedsubsequently, the implementation of the pull model at a higher level ofabstraction may generally include the following interactions between theDVR 37 and the RNS servers 32: modem negotiation between the DVR 37 andthe RNS servers 32 to establish a session; a Peer-to-Peer Pointnegotiation; a URL request being made by the DVR 37; data transfer; andconclusion of the session. By contrast, the push model is defined tomean that RNS servers 32 initiate contact with the DVR 37 to downloadrequests transmitted from the front end 14 a in the nature of recordinginstructions. For example, using the same PPP connection as in the pullmodel, when called, the DVR 37 can engage in a session with the RNSserver 32, for example, if a caller identification matches apredetermined RNS server 32. Alternatively, broadcast tagged recordinginstructions may be used. For example, the Vertical Blanking Interval(VBI) can be used to embed instructions into the broadcast datastream.If a DVR 37 detects its tag (e.g., serial number), the DVR 37 storesassociated instructions in its “to do” list. In this embodiment, the DVR37 should preferably be constantly tuned to a specific broadcast channelin order to receive the data broadcast by the RNS servers 32.

[0132] There are several ways in which the RNS servers 32 may obtaininformation from front end 14 a or from other online data sources, theinformation being ultimately provided to the DVRs 37. These alternativeswill now be discussed. First, referring to the communication system ofFIG. 2, the front end 14 a may push data through the batch requestserver 48 to the RNS servers 32 over data line 58. On a periodic basis,the batch request servers 48 push a database of all of the pendingrequests to all of the RNS servers 32. In one implementation, thepending requests can be contained in a BerkelyDB file. Additionally,another BerkelyDB file can include a list of all of the users who haveregistered their corresponding DVR 37 for use over systems 10A and 10B.When a DVR 37 sends an HTTP request with a corresponding serial numberembedded therein to an RNS server 32, a determination is made as towhether the DVR 37 has been configured to interoperate with systems 10Aand 10B. As described herein, the DVR 37 is capable of instructing theRNS server 32 to provide a list of pending requests by sending a URL tothe RNS server 32.

[0133] As will become apparent to those skilled in the art, RNS requestserver 32 can include similar components in FIG. 3, a description ofwhich has already been described. One particular implementation of amain memory unit 130 for RNS server 32 will now be discussed, by way ofexample, with reference to FIG. 8. When a DVR 37 first establishes asession with the RNS server 32, a URL is sent from the DVR 37 with theserial number embedded therein to the RNS server 32. As seen in FIG. 8,main memory unit 130 includes a first module 132 providing thefunctionality of verifying whether the DVR 37 is properly registered tointeroperate with the systems 10A and 10B. By way of example, module 132can be implemented as a CGI written in Perl script that analyzes theBereklyDB file (containing a list of serial numbers for all DVRs thathave registered) to match the serial number embedded in the HTTP requesttherewith.

[0134] Additionally, the DVR 37 can send another URL to the RNS server32 requesting a list of responses. A second module 134 provides thefunctionality of determining and extracting the pending requests for theparticular DVR 37. By way of example, module 134 can be implemented as aCGI written in Perl script that analyzes the BereklyDB file to match theserial number embedded in the HTTP request with a list of pendingrequests. Upon locating the pending requests, module 134 extracts therelevant information and transmits it to the DVR 37 of interest.

[0135] Also, the DVR 37 can send another URL to a particular RNS server32 indicating a list responses to the requests received from the RNSserver 32. When the list of responses is received by the RNS server 32,another module 136 is included to concatenate the responses into aresponse log file. Third module 136 may also be implemented as a CGIwritten as a Perl script. It will be appreciated that the response logfile concatentates responses from many DVRs 37, and can growconsiderably large in as the distributed back end 16 a scales upward.Accordingly and periodically, the RNS server 32 pushes the response logfile to the database 44 through the batch request server 48. Thisenables database 44 to be updated with responses, that can include byway of example, a new channel lineup, a new Replay Guide, a list ofrequests that the particular DVR 37 has successfully processed, andcorresponding errors. To implement the push function, by way of example,a standard UNIX command that invokes a CRON job can be included toexecute periodically (e.g., every 15 minutes), thereby pushing theconcatentated list to the batch request server 48. As is conventionally,known by those familiar with UNIX, a CRON job handles the execution ofshell command lines at specified intervals.

[0136] Referring to FIG. 5, another embodiment of the communicationssystem 10B is shown. FIG. 5 is similar to FIG. 2, except for theaddition of the TMS FTP server 112 coupled to the converter module 116(referred to interchangeably as the Cruncher module 116) and to theMREPG module 114. The TMS FTP Server 112 is an online data source ofprogramming data which is translated into a localized EPG format. TheEPG retrieved from server 112 is transmitted to database 44, whileselected portions of the EPG are transmitted to the DVR 37 via theCruncher module 16 and the RNS server 32.

[0137] Referring to the block diagram of FIG. 9, the data flow ofselected EPG data from the TMS FTP server 112 to DVR 37 is shown,wherein such EPG data is pushed from TMS FPT server 112 towards the RNSserver 32 through the Cruncher 116. In one implementation, the Crunchermodule 116 periodically collects EPG data from the TMS FTP server 112,constructs the Channel Guide and ReplayZone data, and feeds suchinformation to the RNS servers 32. In the particular implementation, theCruncher 116 can be designed to run a CRON job that periodically wakesup and downloads TMS data files from server 112. The Cruncher 116 can beimplemented using scripts (e.g., Perl scripts) that “crunch” (i.e.,decompose) the EPG files into many individual files in a format suitablefor the DVR 37. These formatted files can also include SUZUKI datainserted therein. SUZUKI data includes a collection of genre-based showshaving identification tags associated therewith. These tags can in turnbe used by system 10B to filter certain genres of show for the user toselect, referenced for convenience as the Replay Zones feature. Underthe control of the Cruncher 116, an RSYNC command known in UNIX can beused to distribute these files to the RNS servers 32. As conventionallyknown, the RSYNC command allows the transfer of data using a securechannel.

[0138] With either the push, pull or broadcast models described herein,the RNS servers 32 are a distributed load-balanced set of servers thatreceive these files from the Cruncher 116 and receive requests fromfront end 14 a. When an Internet connection is established between theDVRs 37 and the corresponding RNS server 32, the DVRs 37 receive thedata stored in the RNS server 32. For example, every show in the ChannelGuide is associated with a unique definition specified therewith that ispushed from the front end 14 a to DVR 37. The DVR 37 matches this databased on other data it receives from the Cruncher module 116. The DVR 37includes a list of program data in its Channel Guide, and based upon thematching and the data received from the Cruncher 116, constructs itsChannel Guide.

[0139] Regarding the upload of EPG data to the database 44, the MREPGmodule 114 comprises a batched process implemented by software and thatextracts data from the TMS FTP server 112 to update database 44. TheMREPG module 114 is responsible for providing the TV program guidecontent to the database 44. Module 114 also provides a search featureallowing users to find shows based on their title, description and/orcredits. Furthermore, module 114 also is responsible for maintaining theEPG data in database 44 and keeping such data up-to-date based on theTMS feed. The Channel Guide that is sent to browser 20 is constructedfrom EPG data from database 44, and that is loaded by the MREPG module114. The DVR 37 has a Channel Guide that is constructed by the Crunchermodule 116 and loaded through the RNS server 32. Accordingly, there aretwo versions of the Channel Guide, one in database 44 and the other inthe DVR 37, albeit both originating from the TMS FTP server 112. Thereason for this dual loading of TMS data in database 44 and in the DVR37 for the Channel Guide is for the purpose of providing only necessaryChannel Guide data to the DVR 37 so as to prevent unnecessary memoryallocation thereon.

[0140] Reference is now made to an implementation shown in FIG. 9, wherea Log-Mill module 140 collects all of the logs from the DVRs 37, each ofwhich includes a system log file that accumulates administrative systemtasks. As this system log file grows in size, it is archived from thedata storage of the DVR 37 to free up memory space. An application canbe included on DVR 37 to upload the system log file to the RNS server32. Once the system log file is uploaded to the RNS server 32, Log-Millapplication module 140 can archive it (257, 259 in FIG. 13B) to adatabase 142. One example of doing so is for the Log-Mill module 140 toexecute a CRON job that periodically wakes up to use the RSYNC routineto retrieve the system log files distributed across all RNS servers 32,that coalesces them, and that feeds them to database 142. It will beappreciated that database 142 may be separate from database 44. In oneexample where database 142 is provided from Oracle, a SQL*Load commandis invoked by the Log-Mill module 140 to archive the system log files inthe database as entries. Archiving the system log file enables usagetracking, that is, tracking the number of users utilizing certainfeatures of the DVR 37. The Log-Mill is also useful for collectinginformation used for statistical calculations, billing, establishingprojections, and targeting advertising, products, and content.

[0141] ii. Media-Based Devices and Appliances

[0142] The media-based devices and appliances 36 will now be discussedin more detail by referring to a general embodiment of the hardwareshown in FIG. 3, by way of example, and occasionally to FIGS. 13A-B. Forconvenience and ease of understanding the invention, like referencenumerals are referenced for similar components previously describedregarding FIG. 3, a portion of which are applicable to media-baseddevice and appliances 36. In the embodiment of FIG. 3, media baseddevice 36 includes a control input device 68, a first network controllerand interface (I/F) 70, and an I/O device 72, coupled together via bus74. Optionally, media-based device 36 can optionally be coupled to orinclude a display device 64, and can optionally include a second networkcontroller and interface (I/F) 73, and a keyboard 66 coupled togethervia bus 74. It will be appreciated that device 36 can include more orless components than those explicitly described here. Media-based device36 further includes a control unit 62 having a processor 76, memory unit78, and a data storage device 80 also coupled to bus 74.

[0143] According to one implementation of FIGS. 2 and 5, a first networkcontroller and I/F 70 may facilitate the communicative coupling of themedia based device 36 to the batch request server 48 of front end 14 aover data line 60. Optionally, a second network controller and I/F 73may be coupled to other network and devices not explicitly shown. Theprocessing unit 76 processes data signals and may comprise variouscomputing architectures as already discussed with respect to clients 18and servers 28.

[0144] Referring now to FIG. 4D, further details of a particularembodiment of a main memory unit 78D for a media-based device 36 areshown. In the embodiment of FIG. 4D, the memory unit 78D preferablycomprises an operating system 84, other applications 87, and a networkapplication 85, the functions of which have already been described. Mainmemory unit 78D further includes a video capture engine 150, atransaction handler (application) program 152, and a request handler(application) program 154 all communicatively coupled together viasystem bus 74. Optionally, a browser 82 may be included.

[0145] As noted above, the main memory unit 78D stores instructionsand/or data that may be executed by processing unit 76. The instructionsand/or data may comprise code for performing any and/or all of thetechniques described herein. These modules 82, 84, 85, 87, 150, 152, and154, in addition to others not specifically shown, are coupled by systembus 74 to the processing unit 76 for communication and cooperation toprovide the functionality of the media-based device 36. Those skilled inthe art will recognize that while the present invention will now bedescribed as modules or portions of the memory unit 78D of acomputer-based system, the module or portions may also be stored inother media such as permanent data storage and may be distributed acrossa network having a plurality of different computers such as in aclient/server environment.

[0146] In general, it is noted that media-based device 36 may includethe functionality described with respect to FIG. 4D, or equivalent, aswell as additional functionality not explicitly shown. The presentinvention can be implemented in a wide range of devices and is notlimited to the embodiments described herein. Examples of media-baseddevices 36 can include, but are not limited to home appliances,interactive televisions, portable network televisions, portablenetworked devices having television functionality, or set-topapplications and devices.

[0147] Referring to FIG. 10, one type of set-top device that iswell-suited for use with the present invention is shown and embodied asan interactive television sub-system 160 comprising a Digital VideoRecorder (DVR) 37, such as those available from ReplayTV, Inc. ofMountain View, Calif., by way of example. For convenience, the DVR 37will be interchangeably used with a “video replay system 37.” In theexample of FIG. 4, the DVR 37 is coupled to television-based displaydevice 162 for viewing broadcast content (i.e., programs) from abroadcast provider 164. Program 166 (e.g., a television program) isreceived from a national broadcaster 164 and is passed to the displaydevice 162, along with other content, data and control data 168 (e.g.,such as ads, programming guides, and control input from a network).

[0148] Referring back to FIGS. 3 and 4D, the DVR 37 is a client-basedsystem having similar functionality to that previously described withclient 18. For example, DVR 37 includes a data storage device 80, suchas a hard drive, which is used to store the incoming program signal 166.The saved signal can then be viewed at a later time or can be viewedimmediately from the storage medium 80. The DVR 37 includes a processor76 and a memory unit 78D (or similar components used to direct thefunctionality of the unit) and implements the described functions forthe particular device 37. Further, DVR 37 can make decisions whendisconnected from the initial source of content 166, that is, whenfunctioning as a stand-along device.

[0149] In one embodiment in accordance with the present invention, theDVR 37 receives control information 168 over a network as indicated bydata line 34 from a network server, which in a particular embodiment isdescribed herein as the load-sharing “RNS” servers 32. Control lines 34indicate that a communication link is present coupling the DVRs 37 tothe respective RNS server 32. Content information 166 can include, butis not limited to, electronic advertisements, electronic program guides,authentication information, control input originating from a client 18,and other types of data from online sources and databases describedherein. In response, DVR 37 can transmit control information 168, suchas advertisement impressions, accounting information, and updatedprogramming and profile information to the servers 32 and 48. It shouldbe understood that the sub-system 160 can receive various types ofprogramming, including but not limited to cable content, televisioncontent, high definition TV content, digital TV content, pay per viewcontent, and content broadcasted over a network, including the Internet.It should also be understood that display device 162 can be anyappropriate type of display device, including but not limited to adigital or analog television set, an Internet appliance, a cellulardevice, or a wireless device. The DVR 37 and the display device 162 maybe separate physical devices as shown, integrated together, or brokeninto even more functional units than shown.

[0150] It will be understood that one implementation of the DVR 37includes a telephone line to implement one or more of control lines 34and 60. For example, such control lines 34 and 60 can include an RJ-45(Registered Jack-45) connector, and in other implementations, caninclude an Ethernet connection or Token Ring Type 3 communications. Inthe system 10A shown in FIG. 2, the information 168 is passed to andfrom the DVR 37 on a regular basis (e.g., such as every 24 hours) aswill be described in the “batched” mode operation. Other implementationsuse an Internet connection as data control line 34 and 60 and connectregularly or on a more frequent basis. For example, in the additionalembodiment of system 10B shown in FIG. 5, the information 168 is passedbetween the DVR 37 and the client 18 in a real-time mode, with nearinstantaneous results. Still, other embodiments of control lines 34 and60 may be a wireless communication medium as will be known in the art.

[0151]FIG. 10 also shows a remote control device 170, which is used tocontrol the sub-system 160. Typically, DVR 37 will also include controlinput in the form of a touch panel disposed on the housing of thedevice. As will be described subsequently, one aspect of the presentinvention comprises the user control of the media-based device 36 beingenabled over communication systems 10A and 10B. For example, in aparticular embodiment, the sub-system 160 can be controlled over theInternet.

[0152] The context in which the described embodiment operates is with anindividual user's DVR 37, although the invention is not intended to belimited to interactive-television sub-systems 160. For example, othertypes of media devices and appliances 36 are shown in FIG. 2. Generallythough, with a DVR 37, a user selects program content by replayingpreviously recorded “taped” content from a hard drive or similar storagemedium 80 or by turning on his television (or other content source) andselecting a program or show to watch. As the selected program content isreceived by the DVR 37, it is first stored on the storage medium 80 andthen displayed on a display device 162 such as a television set ormonitor 64.

[0153] Referring back to FIG. 4D, the various modules representingsoftware applications and programs executing in main memory unit 78D ofa DVR 37 will now be discussed in detail with occasional reference toFIG. 10, for ease of understanding the present invention. The DVR 37receives signals from a national broadcaster 164, such as a television,cable, or pay-per-view broadcaster that broadcasts one or more programs166 (such as a video broadcast). The broadcast is received by the videocapture engine 150 in memory unit 78D. The video capture engine 150passes the captured programming content to a storage medium 80 as it isreceived and to a display device 162 upon user selection. Video captureengine 150 can be coupled to a tuner (if needed, but not explicitlyshown) to indicate which of the possible broadcast programs 166 the userhas selected, i.e., by changing the channel. The user can then choose toeither display the program 166 as it is being received or save theprogram 166 for playback at a later time (or both).

[0154] The user at client 18 generally is provided with functions to:add a program listing to the guide; delete a program from the guide;update the program listing on the guide; obtain the guide from the DVR37; and obtain the channel guide from the DVR 37. In one implementation,and by way of example, these types of control input requests, commandsand instructions provided by the user at client 18 can be stored in atransaction file in the front end 14 a, and pushed to the back end 16 a,ultimately being transmitted to the DVR 37 through the RNS servers 32.

[0155] Reference will occasionally be made to the sequence diagram ofFIGS. 13A-B when describing the “batched” mode implementation.Periodically, the DVR 37 dials 249, 253 into a network (e.g., Internet)to communicate with RNS servers 32, and requests the transaction file tobe downloaded 251, 255 to the DVR 37. To facilitate this communication,DVR 37 includes a network application module 85 that generally controlsthe frequency and time that connections to the RNS servers 32 are made.The network application module 85 also controls what data is transmittedto and received from the RNS servers 32.

[0156] In one implementation, the DVR 37 can obtain requests from theRNS servers 32 by parsing a request list and creating a file for eachrequest. The file can be appropriately named according to the contents,and can be formatted in XML. The request handler 154 is notified whennew requests have arrived at the DVR 37. To perform these functions, andby way of example, when control line 34 and 60 are interpreted to be anetwork connection, like communicating with the Internet, DVR 37 canestablish a point-to-point protocol (PPP) connection to the Internet tocommunicate via http commands with the RNS servers 32. DVR 37 includes aHTTP/PPP client module 156 as shown in the main memory module 78D ofFIG. 4D, which under the control of the network application module 85,generally enables the DVR 37 to establish a PPP connection with RNSservers 32 by using a communications protocol for enabling dial-upaccess to the Internet. By doing so, http transmissions 253 may be madefrom DVR 37 to the RNS servers 32. More specifically, a PPP connectionuses an Internet protocol that provides a standard way of transportingdatagrams from many other protocols over point-to-point links, as isconventionally known in the art. A PPP connection between the DVR 37 andserver 32 allows the connection over a regular telephone line, therebyenabling the DVR 37 to be a network participant. Module 156 can beprovided with additional functionality to enable the PPP connection byestablishing and terminating a session, in addition to hanging-up andredialing functions with the gateway to the Internet. From theperspective of each DVR 37 functioning as a client, there is one RNSserver 32, namely corresponding to the URL rns.replaytv.net, by way ofexample. One benefit of the PPP connection is that it permits directfile transfers between DVRs 37 and servers 32, as opposed totransferring a file to a dial-up computer and downloading the file intothe system. Alternatively, the PPP connection can be implemented on afull-duplex link by dialing into high-speed DS1 and DS3 lines.

[0157] The DVR 37 establishes a session 253, 255 with the RNS servers 32to enable the transaction file to be downloaded to the DVR 37. Forexample, several exemplary features under the control of the networkapplication module 85 include: (1) downloading the Channel Guide datafrom the front end 14 a; (2) downloading the ReplayZone data from thefront end 14 a; (3) downloading new software upgrades from the front end14 a; and (4) uploading log file information from the DVR 37 to thefront end 14 a. One manner of implementing these four functions is forthe DVR 37 to provide http requests to the RNS server 32, which inresponse uses a CGI-gateway to invoke Perl scripts that fulfill therequests received from the DVRs 37.

[0158] Upon receiving the transaction file, the DVR 37 includes atransaction handler module 152, as seen in FIG. 4D. The transactionhandler 152 parses the transaction file into requests and calls arequest handler 154 for each request.

[0159] The request handler 154 executes the request, checking for apossible conflict and returns a response for each request. Each of theseresponses can be formatted with XML in the same embodiment. Thetransaction handler 152 compiles the responses into a transactionresponse file and returns the file to a RTVS Communicator module 158.The RTVS Communicator module 158 functions to upload the transactionresponse file to the RNS servers 32 when the network application 85controls the periodic automatic dial-up to the Internet to communicatewith the RNS servers 32.

[0160] In a particular implementation, a set of routines may be includedin the other applications 87. One such routine gets requests by parsinga request list under the control of the request handler 154 and createsa corresponding file. The information that may be contained in therequest file can include a request identifier, the command to execute,and the target interface on which to perform the command. For example,the request file may contain a unique identifier associated with thecommand “AddReplayChannel” on the Replay Guide interface. When newrequests arrive at the DVR 37, the request handler 154 is notified andprocesses each request and places the results in a “results” file. Byway of example, the “results” file can be designed to include anindication of the success of the command for the unique identifier, theparticular results generated by performing the command, and a timestampassociated therewith. It will be appreciated, that the described requestand results files are merely exemplary and that other implementationswould work suitably well with the present invention.

[0161] Various features that may be included in the other applicationsmodule 87 will now be described. Module 87 can be designed toaccommodate a request to add a single show. This module is used to addrecord events as specified after checking for conflicts or free diskspace availability. Table 1 below lists exemplary data that can behelpful in creating a data structure to be used by such a module. TABLE1 Start time Duration (e.g., in minutes) Encoder Quality Level Source ofInput of Show Index of channel in Channel Guide TMS ID used for sanitycheck Indicator to force a raw record mode for time-based recordrequests Indicator of a guaranteed record Indicator to record allepisodes Indicator of the number of episodes

[0162] The application module 87 can further include the capability toadd a show-based Replay Channel using the quality and guaranteed statusfrom the show. Based on the number of episodes and duration of the show,the calculation of available memory space 80 should preferably beperformed. In addition to the exemplary data listed in Table 1, thefollowing additional data can be included in the data structure: 1) thename of the Replay show to be added; and 2) the name of the ReplayChannel to be added. This same combination of exemplary data can be usedto accommodate a request received by the DVR 37 to add multiple shows.

[0163] When the request received involves adding a theme-based ReplayChannel, application module 87 can include functionality to calculateavailable memory space 80, based upon the duration of the theme-basedshow, the encoder quality level, and the indicator of guaranteed values.Table 2 below lists exemplary data that is desirable in creating a datastructure to be used by such a module. TABLE 2 Name of Replay Theme Nameof Replay Channel Duration (e.g., in minutes) Encoder Quality level Flagdefining what is searched Source of Input of Show Indicator to force araw record mode for time-based record requests Indicator of a guaranteedrecord

[0164] Requests received at the DVR 37 can also be directed to deletingscheduled record requests that are maintained in a record list.Accordingly, application module 87 can include functionality to delete ascheduled show from the record list on the Replay Channel. Table 3 belowlists exemplary data that can be helpful in creating a data structure tobe used by module 87 to provide this functionality. TABLE 3 Start timeIndex of channel in Channel Guide Indicator to force a raw record modefor time-based record requests

[0165] Application 87 can also include functionality to accommodate arequest received at DVR 37 directed to deleting a Replay Channel. Toenable this functionality, the Replay Channel id corresponding to a showshould be provided in the request.

[0166] Furthermore, application 87 can include functionality thatenables the user to change the parameters of the channel, like forexample, the hours guaranteed. Once the parameters are changed, theReplay Channel is updated, including checking for conflicts andavailable memory space 80, providing notification of the success of theupdate.

[0167] Additionally, application 87 can provide functionality to changea static Replay Channel to a show-based Replay Channel. Exemplary datathat can facilitate this function includes: 1) the name of the Replayshow; and 2) the name of the Replay Channel.

[0168] Other functionality for application 87 includes accommodatingrequests received to obtain the Replay Guide from the DVR 37, as well asthe Channel Guide. Given the described functionality of the applicationmodule 87, one technical advantage that will be appreciated by thoseskilled in the art is that the corresponding requests received at theDVR 37 may be treated as though originating from standard interactions,and incorporated into a “to do” list. Whether the pull, push orbroadcast flow of data is used, the DVR 37 does not require addedinfrastructure, and thus additional custom software is not required.

[0169] E. An Exemplary Method for Batched Processing of theCommunication System

[0170] The process of a preferred method for the user to control the DVR37 or to access related information is now described. The process beginswith user authentication on the Internet initiated by a user requestinga home page such as 180 shown in FIG. 11. Those skilled in the art willreadily appreciate that a URL (Uniform Resource Locator) on the worldwide web is utilized in order to locate the home page 180. If the useris a new user to systems 10A and 10B, he is provided the opportunity toregister through a web server 28-1 . . . 28-n. For the user who hasalready registered, he may log in by entering personal information (e.g.user name 182 and password 184) from home page 180. More details of theauthentication process are described later.

[0171] Once the authentication is successfully accomplished, the webserver 28-1 . . . 28-n initiates one or more steps through the API togenerate the first web page of information representing the userinterface of DVR 37 that a user sees after login. An example of thisfirst page of information is shown in FIG. 12A. It will be appreciatedby those skilled in the art that this information may be generated basedon state information, which may be indicated by a default value, by thesystem administration, or by the cookie information (i.e. informationrelated to how certain web pages have been used in the particularbrowser stored in small data files, or cookies, residing locally in thebrowser computer) embedded in the HTTP request originating from thebrowser 18. For example, the information that is eventually returned toa user who has just completed the login process could include an EPG(electronic program guide of channels) as seen in FIG. 12A, a ReplayGuide, a “find shows” page, and a “manual record” page. The latter arefurther described below.

[0172]FIG. 13A is a data flow diagram illustrating the process 230 ofone method for a user to obtain information from and provideinstructions to systems 10A and 10B. FIG. 13B is a sequence diagramillustrating further details regarding the data flow of FIG. 13A.Throughout this figure, data flow lines (used interchangeably with“steps”) reflect an order in which part of the method is preferablypracticed. In the description to follow, occasional reference will alsobe made to FIGS. 2 and 5. Before the process 230 of obtaininginformation from and providing instructions to system 10A and 10Bbegins, a user navigates to 229 a website for one of the servers 28-1, .. . , 28-n, which responds with an appropriate web page 231. The process230 begins with the user login 232 into system 10A or 10B. A user entersidentifying information, as for example, in the user interface 180 ofFIG. 11. A user name and password are transmitted from the clientbrowser to the database as indicated by steps 232, 234 and 236 in FIG.13B. Once the user is authenticated with predetermined information onthe database, a first page 190 of information such as an EPG as shown inFIG. 12A is formulated 240 from data received from the database 238, andis forwarded 242 to client browser 20. Such first page 190 ofinformation, as well as subsequent pages, may include drop-down menussuch as those illustrated in FIG. 12B, as well as buttons such as the“Go” button 192 seen in FIG. 12A. The user may select a desirable entrywithin each drop-down menu and/or click on the “Go” button 192 to invokea command. Upon doing so, the browser 20 sends a HTTP request to analready connected web server such as 28-1, as shown in step 232. Thoseskilled in the art will recognize that the drop-down menu andbutton-driven features may be implemented in a variety of ways.

[0173] Once the HTTP request is received at server 28-1, the server 28-1will initiate the appropriate steps, or make the appropriate functioncalls, within the context of the API on the middle tier server 40, asindicated in flow line 234. The step further involves communication 236between the middle tier server 40 and the database 44. Flow line 236illustrates the steps in which the middle tier server 40 obtains therequested information from or stores instructions into the database 44.One manner for doing so is with JDBC (Java DataBase Connectivity,otherwise known as the Java™ database API) wherein raw data is sent fromthe middle tier server 40 to database 44. The database 44 will returnthe requested data preferably, although not required, in a raw format tothe middle tier server 40 as indicated by flow line 238.

[0174] The middle tier server 40 then assembles the retrieved data andupdated information into formatted data, which are forwarded 240 to theweb server 28-1. It is noted that the API on the middle tier server 40includes that programmable logic to package (i.e., format) data receivedin a raw format into a form that is well-suited for flexibly definingdata structures. One format that is advantageous is XML because itallows the tagging of data in a manner that is not tightly coupledtogether, thereby providing more flexibility in defining datastructures. Other formats, though, will work suitably well with thedescribed embodiments of the present invention, including HTML. Theabove step 240 is followed by step 242, whereby the server 28-1 in turnassembles and forwards a presentation, having a format that iswell-suited for the client browser 20 (e.g., in HTML, Java, JavaScript),to browser 20. In an alternative embodiment, another format that workswell with this presentation is WML (or Wireless Markup Language, an XMLlanguage used to specify content and user interface for wireless devicesuch as mobile phone browser), provided that the system 10A and 10B ismodified for wireless media client-server access when using WML. It willbecome readily apparent to those skilled in the art that the processsteps shown in FIG. 13A are flexible in the nature of accommodating avariety of contexts related to user requests, e.g., requests forinformation and for recording specified programs. Steps 234′, 236′,238′, 240′ and 242′ indicate further communication between the client18, server 28, middle tier server 40, and database 44, similar to thosesteps already described.

[0175] The middle tier server 40 enables communication between variousweb portals 28-1 . . . 28-n and the database 44 through an API, whichfacilitates the communication of user instructions and operations forcontrolling the DVR 37 with the front end 14 a. One technical advantageof the API is that it allows a portal (e.g., 28-2) to cache informationreceived from the middle tier server 40 locally within the environmentof the particular portal such as 28-2 with a frequency based upon when auser is interested in the information. Furthermore, the API of thedescribed embodiment of the present invention is flexible so as topermit a portal 28-2 to present the content of information from themiddle tier server 40 in a manner that enables display of informationusing proprietary types of graphical user interfaces (i.e., GUIs)distinctive to those system administrators operating the particularportal (e.g., 28-2). Business logic (e.g., checking of time conflictsfor recording, disk space) may be included in the middle tier server 40to form a part of the API that provides a standardized mechanism forreceiving requests forwarded from the portals 28-1 . . . 28-n, and forsending back a corresponding response.

[0176] In order for the web server 28-1, . . . ,28-n such as portal 28-2to present the interactive television device data at the web browser 20,each web portal is enabled to use, copy, encode, store, archive,distribute, transmit, modify, translate, render into an audible format,publicly display and publicly perform the content received from database44, in whole or in part in connection with the property of the webportals 28-1, . . . , 28-n. The API enables the web portals to allowusers at the browser 20 to download and print or perform the content.This content includes the interactive television device data, like forexample, a top watched shows list. The API of the described embodimentsof the present invention permits the content to fit the format andlook-and-feel of the particular web portal.

[0177] As evident from the above discussion, the API plays an importantrole in the front end of the described embodiments of the presentinvention. The API includes data structure definitions, functions thatfacilitate communication between the middle tier server 40 and theportals 28-1, . . . , 28-n, as well as a series of routines thatretrieve and manipulate data in the database 44. A routine is defined tomean a callable algorithm or sequence of steps residing in and formingpart of the API that can be invoked to perform various tasks involvingcommunication with the database 44. The routines of the API may beinvoked by the servers 28-1 . . . 28-n to operate the DVR 37 or toaccess related information stored in the database 44. A list of suchroutines as implemented in the described embodiments of the invention isgiven in FIG. 14. The corresponding input parameters and output filesare listed in FIG. 15. The names of the routines, and of the parametersand files, are designed to be indicative of their respective functions,most of which will become apparent to those skilled in the art. Someless intuitive terms have been previously described with the descriptionof front end 14 a.

[0178] One aspect of the present invention is to enable a user tooperate a media-based device 36 remotely by communicating with one ormore databases through a computer network. Referring to an embodiment ofthe present invention shown in FIG. 16A, a user request 260 is firstreceived and processed, for example, by a web server such as portal28-2. The portal 28-2 translates the request into function call 262 tothe API 264. The routines embedded in the API 264 are then invoked andthe middle tier server 40 on which the API 262 is implemented proceedsaccordingly to communicate 266, 270 with at least one database 268. Thisstep 266 involves providing instructions to control the media-baseddevice 36 and/or retrieving 270 related data from the database 268. Thedatabase 268 itself may be configured as a hub that is in communicationwith the media-based device 68 and other sources of information, whichhave been previously described in FIGS. 2 and 5. After all the routinescalled by the portal 28-2 are executed, the portal 28-2 responds to theuser request by incorporating the results of the execution of theroutines residing in the API.

[0179]FIG. 16B illustrates on a high level how a web server, e.g.,portal 28-2, may utilize the API routines to access and manipulate datain the databases 268 in response to various user requests 260 inaccordance with one embodiment of the present invention. Note thatdatabase 44 in FIG. 2 and in FIG. 5 is merely illustrative, and that theembodiment shown in FIG. 16B, which illustrates four databases 280, 282,284 and 286 each of which will be described below, works suitably well.The API routines 264 shown in FIG. 16B are designed to extract data fromand to insert instructions into the databases 268. The predominantdirections of data flows are indicated in the figure by the directionsof the arrows connecting each routine to one or more databases. However,some parameters or exchange of triggering data is presumed to haveoccurred before any substantial amount of data is transferred to or fromthe databases 268. The database 280 contains information related to theuser and comprises, for example, a replica of a commercialauthentication database such as SilkNet™ and additional user profiledata. This database is accessed by the API routines CreateAccount 288,Login 290 and GetProfile 292 that together authenticate a user andinitialize communication between the user and the systems 10A and 10B,through the server 28-1 and the middle tier server 40. The box profiledatabase 282 archives information related to individual media-baseddevices, including the respective channel lineups. This database 282 isaccessed by GetProfile 294 as well as GetChannelLineUp 296 in responseto a user request to view information related particularly to the DVR 37that the user wants to operate. The EPG database 284 may either be acommercial database such as an online service 54 or a databasecontaining already extracted information from a commercial source. Thisdatabase 284 is accessed by GetEPG 298 and ShowGuide 300 to retrieveprogram information. Lastly, the box transaction database 286 includesinformation related to programs recorded by the DVR 37 and requests forthe DVR 37 to record future programs. This database 286 exchangesinformation with the middle tier server 40 every time a request is madethrough the AddRequest routine 304, or DeleteRequest routine 306. It isalso accessed in response to user >requests to view related informationthrough GetReplayGuide 302.

[0180] The GetEPG routine 298 provides the function of retrieving an EPGthat has been customized for a particular user. One particular manner ofdoing so is for module 298 to accept user input from the instructionreceived from client 18, and to return a document of the user's EPG. Byway of example, the user can include various identifiers, like the userid, the id of the particular DVR, the start time and duration of the EPGbeing requested, the staring channel, and the number of channels to bedisplayed.

[0181] The GetChannelLineUp routine 196 provides the function ofretrieving the channel lineup of a particular DVR 37. This lineup may beretrieved if the user provides, for example, the user id and the id ofthe particular DVR 37. This information retrieved may depend on theavailability of various program channels to the DVR 37 because of theservice subscribed (e.g. cable or satellite disk service) and on thepreference of the user who may have customize the lineup (e.g. bydeleting certain channels). In some embodiments, a call to theGetChannelLineUp routine 296 may be embedded in the GetEPG routine 298so that a single call to the latter can retrieve an EPG customized for aparticular user as well as a particular DVR 37.

[0182] The ShowGuide routine 300 provides the function of retrieving thedetailed description of a show as available, for example, from acommercial source providing EPG information (e.g. TMS feed), based onthe user id, the id of the DVR, the start time, and the level of detailrequested. Additionally, the routine 300 can search the detailedinformation of all available shows to find shows that fit the user'sinterest as suggested by attributes such as the show title, the actors,the director, etc. In that case, the user can provide the query criteriaincluding attributes and word or phrase to match, and the ShowGuideroutine 300 will return a list of shows as the search result. As for theGetEPG routine 298, the ShowGuide routine 300 may include a call to theGetChannelLineUp routine 296, depending on the implementation.

[0183] The function and mechanics of most other routines illustrated inFIG. 16B will become apparent to those skilled in the art in light ofthe description provided in FIGS. 14-15. However, the AddRequest routine304 is now further described in FIG. 17, and includes a set of routinesthat allow the user to make different types of requests. As illustratedin FIG. 17, these requests may range from those simple for updating ofthe status of the DVR 37 (i.e., Reqtype=none) to those for programrecording (Reqtype=show or Reqtype=theme) and deletion (Reqtype=update).The recording requests can be specified by show or by time and programchannel (i.e. manual recording requests). They can also be based onthemes corresponding to specific search criteria or corresponding toReplayZones, as for example identified by Suzuki identifiers.

[0184] The above discussion outlines a basic structure for the front-end14 a operations of an embodiment of the present invention. Thisstructure provides a web server such as portal 28-1 with a series ofoptions for responding to requests made by users. These options arebased on the API 264 implemented preferably in the middle tier server40. In what follows, several exemplary methods to invoke the variousroutines will be described, taking into account elements of userinterface design. For example, reference is made to the Channel Guide,as illustrated in FIG. 12A. A user presented with this page 190 may viewthe Channel Guide for different time span and different set of channels.He can either jump to the desirable time and channel by selecting theappropriate options in the menu bars 194, 196, and 198, and select thego” button 192, or he can navigate through the Channel Guide using thebuttons 195 and 197. Once the user sees a show of interest to him, hemay select that show and access a pull-down menu such as 218 in FIG. 12Bto see detailed description of the show or to record the selected show.He may also search for other shows similar to the selected one and/orrecord them as he wishes.

[0185]FIG. 18 is a flow chart illustrating an exemplary method 320 for aweb server such as 28-1 to respond to user requests with theanticipation that the user may take any of the above-described actions.The web server 28-1 first verifies 322 that the Channel Guide isup-to-date, in which the information displayed is synchronous withinformation contained in the appropriate databases being accessed thatstore such information. Note, however, that such information may not becurrent because, at least in the batched processing mode, the databasesonly communicate with the DVR 37 at periodic time intervals. If the webserver 28-1 determines (YES branch of 322) that it possesses up-to-datechannel information, the Channel Guide is displayed 328. If not, theserver 28-1 calls 324 the GetChannelLineUp routine 296 and calls 326 theGet EPG routine 298 to update the information before displaying 328 theChannel Guide. The channel lineup is specific to each DVR 37 and isrequired as a filter for the EPG data, so that information concerningprograms not available to the DVR 37 are screened out. The user cannavigate the Channel Guide, as described above, until he chooses to doone of several things. For example, if he requests 330 to see detaileddescription of a show or to find similar shows, the web server inresponse invokes 332 the ShowGuide routine 300 and displays 334 theinformation retrieved. If, on the other hand, the user chooses 336 torecord selected shows, then the web server 28-1 will call 338 theAddRequest routine 304 and display 340 the updated information, whichmay indicate, for example, that the request has been processed or thatthere is no space left in the DVR 37 for such recording. Depending onthe implementation, the updated information may be presented in amodified Channel Guide as shown in FIG. 12A, or in a Replay Guide asshown in FIGS. 19A-B.

[0186] It must be emphasized that the ways in which the server 28-1 mayaccommodate the user and the options available to the user depend on theimplementation of the user interface. The method in FIG. 18 and theoptions discussed above, for example, correspond to the channel lineupdisplay implemented according to FIG. 12A, including the drop-down menusas illustrated in FIG. 12B. A different implementation of the userinterface will result in other request options available to the user.For example, implementing the drop-down menu 220 or 222 will allow theuser to change the recording options in the channel lineup display page.The same dependence on the user interface implementation applies to allthe exemplary methods and the corresponding flow charts discussed below.

[0187] The Replay Guide shown in FIGS. 19A-B illustrate one method topresent the Replay Guide information. The presentation 350 in FIG. 19Ashows the information as organized by Replay Channels, which may bebased on individual shows or on specific themes, as discussed above. Analternative way to present the Replay Guide information is shown in FIG.19B, where the recorded shows are displayed in a Replay Show page. Ineither case, one main option available to the user is to delete one ormore shows. In the case of the presentation of FIG. 19B, another optionis to delete one or more requests to record future shows. Again, theactual implementation of the Replay Guide determines what options areavailable to the user.

[0188]FIG. 20 is a flow chart illustrating an exemplary method 360 forthe web server 28-1 to respond to user requests in correspondence withthe presentation of the Replay Guide information as shown in FIGS.19A-B. The web server 28-1 first determines 362 if it possessesup-to-date Replay Guide information. If not, it invokes the API routinesGetReplayGuide 302 in step 364, and AddRequest 304 (with Reqtype=none)in step 366 to update the information. Calling the latter routine isnecessary if there are previously pending requests that may or may nothave been fulfilled by the time the Replay Guide information isrequested. Once the Replay Guide information is displayed 368, the webserver 28-1 may entertain requests from the user to delete previouslyrecorded shows or to cancel previous requests to record future shows. Ifdeletion of recorded shows is requested 370, the server 28-1 calls 372AddRequest 304 (with Reqtype=Update and Updatetype=DeleteShow orDeleteChannel) to forward the request to the box transaction database286. An updated Replay Guide is then displayed 374. If cancellation ofpending requests is requested 376, the server 28-1 calls 378DeleteRequest 306 to accomplish the cancellation and then displays 380the updated Replay Guide. In this situation, pending requests are thoserequests residing in the database 44, and in general, a response fromthe DVR indicating that the request has been processed has not yet beenprocessed by server 48 nor received by database 44. In each case, thebox transaction forwards the request to the DVR 37 in a batcbed process,for example, in the next pre-set periodic connection session.

[0189] The flow chart of FIG. 21 corresponds to the case when the ReplayGuide information is presented in the Replay Show form illustrated inFIG. 19B. In this case, a method 390 where a user may request thedeletion only of recorded shows since he does not have access to thepending requests. First, the web server 28-1 determines 392 whether itpossesses up-to- date Replay Guide information. If not, GetReplayGuide302 is called 394 before the Replay Guide in the form of FIG. 19B isdisplayed 396. The user may request 398 to see the detailed descriptionof a show listed in the Replay Guide or to see a collection of similarshows. If so, the web server 28-1 calls 400 the API routine ShowGuide300 to retrieve the information and displays 402 the result. If the userrequests 406 the deletion of a selected show from the list of recordedshows, the server 28-1 calls 408 AddRequest 304 (with Reqtype=Update andUpdatetype=DeleteShow or DeleteChannel) to forward the request to theDVR 37 through the box transaction database 286.

[0190]FIG. 22 shows a “find shows” page that allows the user to searchfor shows based on specified criteria. In the exemplary implementationshown, the user types in a search word or phrase and specifies whichfields (e.g., show title and description fields) to search for the wordor phrase. FIG. 23 illustrates the corresponding implementation of amethod 420 for the web server 28-1 to respond to user requests initiatedfrom this find shows page. After displaying 422 the find shows page andreceiving 424 the search word or phrase from the user, the server 28-1calls 426 the GetChannelLineUp 296 and calls 428 the ShowGuide 300routine to effect the search. If one or more shows are found 430 thatconform to the search criteria, the result is displayed 434 so that theuser may request 436 to set up a Replay Channel based on the theme asdefined by the search criteria, or to record one of the shows listed inthe search result. Once such a request is made, the server 28-1 invokes438 the AddRequest routine 304 to forward the request to the boxtransaction database 286 which is in communication with the DVR 37, anddisplays 440 the updated information. In the case when no show is found430 to satisfy the search criteria, an error page is displayed 432.

[0191] Next consider the example “manual record” page shown in FIGS.24A-B. From this page 450 in FIG. 24A, a user can specify the date andtime of a future recording session, as well as the program channel fromwhich the DVR 37 should be recording. Although not shown, an alternativeimplementation of the manual record page 452 in FIG. 24B may allow therequest of repeated recordings at a specified time on selected days ofthe week. As illustrated in FIG. 25, a method 460 for displaying themanual record page is shown. The server 28-1 first displays 462 themanual record page and receives 464 the required information forprocessing the manual recording requests. Then, it calls 466 theAddRequest routine 304 (with Reqtype=show and Showtype=SingleManual orRepeatManual) to forward the request to the DVR 37 through the boxtransaction database 286 and returns 468 updated information to theuser.

[0192] Rounding up this discussion of exemplary methods for the webserver 28-1 to respond to user requests, a preferred method 470 forimplementing the user login to systems 10A and 10B is illustrated inFIG. 26. The flow chart in FIG. 26 represents a method that may be usedwith any web based services. A homepage is displayed 472, followed by adetermination 474 of whether the user is a new user initiating thecommunication. For information gathered 476 on a new user, the webserver 28-1 calls 478 the CreateAccount routine 288. If the user's inputinformation is valid 480, then a call 482 is made to GetProfile 294,from which a default page 484 is determined, otherwise an error page isdisplayed 486. For information in the nature of a username and passwordis gathered 488 for an existing user, a call 490 is made to the Loginroutine 290. Upon authentication 492 of the user information, the server28-1 determines the default page 484 (e.g., an EPG guide) to displaynext after calling 482 the GetProfile 294 routine. Otherwise, an errorpage is displayed 494.

[0193] 2. An Embodiment for Remote Control of Media-Based Devices andAppliances Through On-the-Fly (Real Time) Processing

[0194] Referring now to the block diagram of FIG. 1B, there is shownanother example of a computer-based communications system 19 thatenables the remote control of media-based devices and appliances over acommunication network in accordance with the present invention. In theexample of FIG. 1B, communications system 19 includes a networkcomputing system 15 coupled to a media-based/data integration system 17(referred to as “integration system 17”). The network computing system15 enables multiple users to communicate over a communications system 19in order to access and control the media-based devices and appliances ofintegration system 17 from a remote location. Integration system 17enables the media-based devices to be accessed through thecommunications system 19, thereby further enhancing stand-alonecapabilities of the devices and appliances.

[0195]FIG. 27 shows a block diagram of one embodiment of acommunications system 19A having further details of the communicationssystem 19 of FIG. 1B. In the embodiment shown in FIG. 27, communicationssystem 19A includes a network computing system 15 a coupled to anintegration system 17 a. In particular, and by way of example, networkcomputing system 15 a and integration system 17 a are both based on aclient-server computer model as will be discussed below.

[0196] A. Exemplary Embodiments for the Front End and Back EndSub-Systems

[0197] Referring to FIG. 27, an alternative embodiment of acommunications system 19A is shown. One technical aspect of thisembodiment allows a browser 20 on client 18 to communicate 22 over anetwork 24, such as the Internet, to a media-based device 36 with nearreal-time communication response. In this embodiment, the front endsubsystem 14 a and backend subsystem 16 a have been modified to relocatethe logic therein into a middle tier server 500 within integrationsystem 17 a. By doing so, the network computing system 15 a and theintegration system 17 a can be embodied as two client-server subsystems,which are communicatively coupled together. Network computing system 15a includes one or more client computers 18 preferably having web browser20 running thereon. System 15 a further includes one or more servercomputers 28-1, . . . , 28-n, which are in communication with network24, as indicated by lines 26. For convenience and ease of understandingthe invention, like reference numerals of FIGS. 2 and 5 have been usedin FIG. 27.

[0198] Integration system 17 a includes media-based devices 36 and DVRs37, which are communicatively coupled to one of a plurality of middletier servers 500 via a communications link 60, 34 and 38. DVR 37 andmedia-based devices 36 and servers 500 operate in a client-serverrelationship. The servers 28-1, . . . , 28-n are in communication withthe servers 500 as indicated by data flow lines 30. One or moredatabases 502 are coupled to servers 500. Database 502 is similar todatabase 44 in the nature of storing a compilation of data from variousonline and web hosted sources similar to sources 44, 50, and 54,although this is not shown explicitly in FIG. 27. Furthermore, clientcomputers 18, servers 28-1 through 28-n, and media-based device 36 (andDVR 37) include similar exemplary hardware as described previously withregard to FIGS. 4A-D. Accordingly, a detailed discussion of each ofthese devices is not provided so as to focus on other aspects of system19A.

[0199] Referring to FIG. 28, an alternative embodiment of FIG. 27 isshown, by way of example, to include a load-balanced replicated set ofdatabases 502 and an application server. The Cruncher and Log-Millmodules are rewritten as application server modules, not standalonemodules as in FIG. 9, to enable the rapid development and deployment ofdiverse applications. One particular implementation that is well-suitedfor load-balancing includes a WebLogic Application server 510 providedby BEA Systems, and which may be used for server 500 in FIG. 27.

[0200] As shown in FIG. 28, the WebLogic Application server 510 includesa Cruncher application 116 for extracting data from the TMS FTS server112 and converting the extracted data into a localized format. TheCruncher application 116 is no longer a sstandalone module as in FIG. 9,although it functions to transmit the TMS data to a module foraggregating data into a pool 512 for storage in database 502.Furthermore, server 510 includes an application module 514 enablingcommunication with the RNS servers 32. Another application module 516enables server 510 to communicate with a web servers 518. Both modules514 and 516 are coupled to DB Connection pool 512 to provide and receivedata to and from database 502.

[0201] Reference is now made to FIG. 29 to describe another embodimentof the communications system 550, that uses the WebLogic applicationserver 552 but in a manner different than that shown in FIG. 28. In theembodiment of FIG. 29, the WebLogic application server 552 is coupled todatabase 502, which in turn, is coupled to a Silknet database 50 alreadydescribed herein. A portion of the network computing system 15 aincludes web servers 28, which are coupled to server 552. The RNS server32 is communicatively coupled to database 502 in FIG. 29, unlike theembodiment of FIG. 28. In this embodiment of FIG. 29, communications isstaged through database 502. In general, this configuration uses lessserver resources due to servicing only one means of accessing thedatabase 502. In this embodiment, the database 502 is tuned to performdatabase functions, as opposed to processing many transactions overnumerous protocols. The application server 552 effectively shields thedatabase server from such transactional tasks. According to theparticular implementation, server 552 generally includes an EnterpriseJava Bean container, which facilitates the development of client andserver components in an easy manner. Also, an Apache Xerces and SAX Javaclass libraries 554 can be used for parsing XML documents received atweb servers 28.

[0202] Turning to FIG. 30, another embodiment of the communicationssystem 560 will now be discussed. In the embodiment of FIG. 30, a seriesof layers are depicted, where each layer performs a particular functionin the data pipeline. Components shown in each layer communicate withits neighboring layers through well-defined interfaces. A first layer562, referred to interchangeably as the “presentation layer 562,”produces the HTML pages viewed by the user. Layer 562 receives data inXML format from a second layer 564. Layer 564 is referred tointerchangeably as the “external interface layer 564.” The externalinterface layer 564 presents an externally accessible interface to thoseweb portals 28. To this end, layer 564 serves as an intermediary betweenthe presentation layer 562 and a third layer 566, which is referred tointerchangeably as the “data management layer 566.” The data managementlayer 566 encapsulates all data access and management functionality.Using the Enterprise Java Beans services of the WebLogic applicationserver, layer 566 handles the connection pools to databases 502, 50,manages transactions, manages server component lifecycles, and providesanother layer of load-balancing, if necessary.

[0203] Referring to FIG. 31, the computer-based communication systemsdescribed herein can be designed to provide a high degree of faulttolerance and scalability. As shown in FIG. 31, a network infrastructure580 operates with multiple network centers (or pods) 582 and a globalload balancer 584, which directs traffic to the pods. Although only onepod 582 (e.g., associated with the West Coast) is shown, it will beappreciated that other pods (e.g., on the East Coast, or elsewhere inthe world) can be included, under the management and control of theglobal load balancer 584. To provide data management to support databaseneeds, a local database 586 can be included in each pod. Additionally, amain database 588 (e.g., databases 120 and 126 of FIG. 2) can be locatedat the corporate office of the enterprise. The databases may be keptsynchronized by using built-in facilities of the databases, and by localcaching techiques. The main database 588 is used for archiving purposesand for communicating with external data sources like TMS, and internaldata sources like SilkNet.

[0204] B. An Exemplary Method for Real-Time Processing of theCommunication System

[0205] Referring back to FIG. 27, by coupling two client-server systems15 a and 17 a back-to-back, communication between the client browser 20and the media-based device 36 may be accomplished in near real-timefashion because the device 36 is no longer communicating in a periodicmanner (i.e., batched) with middle tier server 500 and database 502, butis enabled to send and receive commands (e.g., HTTP) to and from servers500, and 28-1 through 28-n.

[0206] As shown in FIG. 27, media-based device 36 communicates with themiddle tier server 500, which also handles requests from externaldevices 28-1 through 28-n. By doing so, a request made from browser 20would be transmitted directly to the middle tier server 500 through webservers 28, and would be provided to the media-based devices 36on-the-fly with near real-time response.

[0207] One benefit of middle tier server 500 is that it providesreal-time access to database 502 without exposing the schema in thedatabase, along with the provision of conflict checking and other datamanipulation functions. Web servers 28 do not need to directly accessthe database 502, but through a set of APIs on middle tier server 500.This is advantageous because the architecture of system 19A is notdependent on the schema nor the database 502. As such, the database 502and schema may be changed while not necessarily impacting the rest ofsystem 19A. Additional functionality, such as conflict checking, can beeasily added to system 19A. For example, the additional functionalitycan be programmed with Java code. Media-based device 36 can alsocommunicate directly with the database 502 through an API, and no longerhave to communicate with servers 32 and 48 as in FIGS. 2 and 5. Thisaspect of media-based devices 36 being able to engage in real-timecommunications also enables them to communicate with one another. Forexample, devices 36 and 37 may communicate with each other throughmiddle tier server 500. In one implementation, device 36 may want toestablish an online “chat session” with or send an email to DVR 37. Ingeneral, there will be two parts of the middle tier server 576. Thefirst part of the middle tier server 576 handles external requests(i.e., to web servers 28), and the second part of the middle tier server500 handles requests from the media-based devices 36 and DVR 37.

[0208] Referring to the particular embodiment of FIG. 28, severaltechnical advantages of the WebLogic application server 510 are nowdiscussed. Server 510 is capable of providing a single method ofaccessing a database 502 through an API for a diverse set of clients,and that it is a mechanism for achieving high scalability for millionsof clients. For convenience, like reference numerals have been used forsimilar components appearing in FIGS. 9 and 28. In FIG. 28, for ease ofunderstanding the present invention, a single server 510 beingrepresentative of an Enterprise Application server is shown to becommunicatively coupled to a single database 502. However, it will beappreciated by those skilled in the art that the implementation of FIG.28 supports multiple load-balanced application servers 510 providingaccess to multiple mirrored databases 502.

[0209] The exemplary API routines discussed previously in detail worksuitably well with this alternate embodiment with minor changes. Themost important difference in this case is that the API routines are nolonger required to access one or more databases, in this case database502. Rather, the routines should be programmed to recognize theadditional option of accessing the DVR 37, preferably through the RNSserver 32. For example, in one implementation, the database may beconfigured with an “insert trigger” which notifies a networked DVR of anew request when the request is inserted. Upon receiving a function callfrom a web server 518, the application server 510 decides whethercommunication should be established with the database 502, or the DVR37, or neither of the two if the information requested is already understorage in some storage module within the application server. Anychanges required in the API routines, however, do not affect the generallogical schemes according to which the routines enable the remotecontrol of the media-based device.

[0210] Other advantages to using server 510 are discussed as follows.First, no software change is required for the media-based device 36 andDVR 37. Second, communication between the external web servers 518 andthe and server 510 may be facilitated through HTTP requests, Javaservlets, or Java applications employing the application modules 514 and516. Accordingly, the RNS servers 32 will either redirect HTTP requestsdirectly to server 510 or will utilize Java servlets to perform therequired communication with server 518. Third, the RNS servers 32 nolonger need to maintain the large collection of files which are mirroredacross the RNS servers 32 as in the embodiment of FIGS. 2 and 5.Instead, with the alternate embodiment shown in FIG. 28, all of the datarequested and provided by the device 36 and DVR 37 are brokered by theRNS servers 32 to the server 510. Fourth, since all data is stored ondatabase 502, the Cruncher application 116 running on server 510 nolonger needs to process and to distribute the files amongst the RNSservers 32. With the embodiment of FIG. 28, the Cruncher application 116retrieves EPG data from the TMS server 112, constructs the Channel Guideusing the retrieved EPG data and stores the constructed Channel Guide indatabase 502. Fifth, multiple applications can be developed to accessthe data stored in database 502, using server 510 as a single point ofaccess thereto. This not only improves scalability and security, butalso the ability to easily and rapidly develop new applications for themedia-based devices 36 and DVR37.

[0211] By contrast with the embodiment shown in FIGS. 2 and 5, the webservers 518 no longer need to communicate with the Tomcat server, but toa WebLogic server 510 in order to load-balance the API. Additionally,these embodiments are beneficial for providing system redundancy, thatis, in the event that one or more servers becomes inoperative or thatcongestion arises with a particular server. Accordingly, HTTP requestsfrom web servers 518 and from media-based devices 36 would be directedto the WebLogic server 510, which would then disperse the requestaccordingly.

[0212] Although the invention has been described in considerable detailwith reference to certain embodiments, other embodiments are possible.As will be understood by those of skill in the art, the invention may beembodied in other specific forms without departing from the essentialcharacteristics thereof. Accordingly, the present invention is intendedto embrace all such alternatives, modifications and variations as fallwithin the spirit and scope of the appended claims and equivalents.

What is claimed is:
 1. A method of uploading data for operating at leastone media device over a network, comprising: receiving a request fordata from at least one first server; responsive to the request received,querying a data source to extract the data for operating the mediadevice; periodically sending the data extracted to the first server, thefirst server being communicatively coupled to the network; andperiodically transmitting the data from the first server to the mediadevice over the network.
 2. The method according to claim 1, wherein therequest is received by a second server, the second server periodicallypushing the data extracted to the first server according to a batchmode.
 3. The method according to claim 1, wherein the data comprisesregistration information associated with the media device.
 4. The methodaccording to claim 1, wherein the data comprises pending transactioninformation associated with the media device.
 5. The method according toclaim 1, wherein the data is transferred in XML format.
 6. The methodaccording to claim 1, wherein the data source comprises databases andonline services.
 7. The method according to claim 1, wherein the datacomprises broadcast programming guides in an electronic format.
 8. Themethod according to claim 1, wherein the network comprises the Internet.9. The method according to claim 1, wherein the media device comprises adigital video recorder.
 10. The method according to claim 1, wherein thefirst server comprises a Domain Naming Service (DNS) server.
 11. Themethod according to claim 1, further comprising a plurality of firstservers for balancing load associated with a plurality of media devices.12. A method of enabling a virtual representation corresponding to atleast one media device over a network, comprising: monitoring datadisposed on a first server until ready for transfer to a second server,the data being associated with the media device coupled to the firstserver over the network; responsive to the data being ready fortransfer, requesting transfer of the data from the first server;receiving the data transferred from the first server; and storing thedata received in a data source, the data being extracted from the datasource to create the virtual representation.
 13. The method according toclaim 12, wherein the data is formatted in XML.
 14. The method accordingto claim 14, wherein the virtual representation is formed by combiningthe data with additional data stored in the data source.
 15. The methodaccording to claim 12, wherein the data source comprises at least onedatabase.
 16. The method according to claim 12, wherein the secondserver requests transfer of the data from the first server with using anhttp request.
 17. The method according to claim 12, wherein the mediadevice is selected from a group consisting of a digital video recorder,a personal digital assistant, a mobile telephone, and a pager.
 18. Themethod according to claim 12, wherein the virtual representation isselected from a group of interfaces consisting of a login interface, aChannel Guide, a Replay Guide, Replay Shows, Replay Channels, FindShows, and Manual Record.
 19. The method according to claim 12, whereinthe data is transferred periodically.
 20. A method of remote controlover a network of at least one media device, comprising: receivingcommands from a first server to operate the media device; responsive tothe commands received, executing the commands to control the mediadevice; producing one or more results in response to executing thecommands; and transmitting the results to the first server over thenetwork.
 21. The method according to claim 20, wherein the first servercomprises a Domain Naming Service (DNS) server.
 22. The method accordingto claim 21, wherein the network comprises the Internet.
 23. The methodaccording to claim 20, wherein the results are transferred in XMLformat.
 24. The method according to claim 20, wherein the media devicecomprises a digital video recorder.
 25. A system, comprising: a firstsubsystem having at least one server coupled to a network, the networkbeing in communication with one or more media devices, the serverenabling the media devices to be distributed with a load-balancedconfiguration; coupled to the first subsystem, a second subsystemmaintaining a virtual representation of one or more user interfacesreplicated from each of the media devices; and coupled to the secondsubsystem, a third subsystem displaying the virtual representation andsimulating operation of the media devices based on portions of the userinterfaces being selected.
 26. The system according to claim 25, whereinthe media devices comprise digital video recorders.
 27. The systemaccording to claim 25, wherein the network comprises the Internet. 28.The system according to claim 27, wherein the server comprises a DomainNaming Services (DNS) server.
 29. A computer program product foruploading data for operating at least one media device over a network,the computer program product stored on a computer readable medium, andadapted to perform operations, comprising: receiving a request for datafrom at least one first server; responsive to the request received,querying a data source to extract the data for operating the mediadevice; periodically sending the data extracted to the first server, thefirst server being communicatively coupled to the network; andperiodically transmitting the data from the first server to the mediadevice over the network.
 30. A computer program product for enabling avirtual representation corresponding to at least one media device over anetwork, the computer program product stored on a computer readablemedium, and adapted to perform operations, comprising: monitoring datadisposed on a first server until ready for transfer to a second server,the data being associated with the media device coupled to the firstserver over the network; responsive to the data being ready fortransfer, requesting transfer of the data from the first server;receiving the data transferred from the first server; and storing thedata received in a data source, the data being extracted from the datasource to create the virtual representation.
 31. A computer programproduct for remote control over a network of at least one media device,the computer program product stored on a computer readable medium, andadapted to perform operations, comprising: receiving commands from afirst server to operate the media device; responsive to the commandsreceived, executing the commands to control the media device; producingone or more results in response to executing the commands; andtransmitting the results to the first server over the network.